From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15114 invoked by alias); 22 Aug 2004 19:31:36 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15045 invoked by alias); 22 Aug 2004 19:31:35 -0000 Date: Sun, 22 Aug 2004 19:31:00 -0000 Message-ID: <20040822193135.15044.qmail@sourceware.org> From: "dave at hiauly1 dot hia dot nrc dot ca" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040812163817.17005.jerrydy@sbcglobal.net> References: <20040812163817.17005.jerrydy@sbcglobal.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1 X-Bugzilla-Reason: CC X-SW-Source: 2004-08/txt/msg02218.txt.bz2 List-Id: ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-08-22 19:31 ------- Subject: Re: wide character strings don't work on HP > John David Anglin wrote: > > >This is a work in progress. In one sense, the patch is complete > >except for documenting the -munix= option. > > > First, thanks for your work: if I understand well, on 11.11, and default > for -munix, we have obtained a clean wchar_t testsuite: great! Yes, that seems to work. > > However, it's dangerous > >to use other than default for this option. > > > > > Unfortunately, I have trouble understanding the details of your concerns: > hopefully, someone else will give you more meaningful advice. My naive > impression is that the new, documented, default, cannot be really dangerous, > by itself and the same for well documented new options. Also, if I > understand well, those options (93, 95, that is) can only lead to a behavior > similar to what we had before your patch... On the other hand, if this is > not the case, in my opinion you could work on adding that possibility. I've thought a bit more about this issue. The fundamental problem is that library code has to be aware of the ABI changes in the different XOPEN UNIX standards if it's going to support more one standard. The interface changes for some functions. In other cases, it's just the operational behavior that changes. Libraries might need conditionalized headers to support these differences. While I could set the __xpg4_extended_mask on a per function basis when I detect the use of a XPG4 extended feature, this isn't a full solution for library code that needs to work with user code compiled using a different standard. For that, library code has to check, set and restore the __xpg4_extended_mask value as appropriate. Thus, I think attempting to provide more than the correct predefines and start files is probably a mistake. If libstdc++-v3 is built with -munix=98, it's not going to work correctly with a user application linked with -munix=93 or -munix=95 as some of the wide character support changes its operational behavior (e.g., wcsftime). I can't really see people that develop library code adding the HP-UX 11 specific tests needed to support multiple XOPEN UNIX standards. It appears that glibc only provides the UNIX 98 multibyte features. I think that for open source code support we want to adopt HP-UX features that match as closely as possibly the features the GNU source features. I need to check if we should default to UNIX 93 or UNIX 95 for HP-UX 10.10 to 11.00 (just discovered that UNIX 95 support started with HP-UX 10.10). Probably, UNIX 95 would be best for GNU compatibility. On the otherhand, UNIX 93 is the HP compiler default and nobody has complained yet... Life would be simpler if GCC only supported one XOPEN UNIX standard on any given HP-UX target (i.e., no -munix= option). However, the option does given more flexibility even if it requires some considerably sophistication to use. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005