public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/17005] wide character strings don't work on HP-UX 11i using gcc 3.4.1 Date: Sun, 22 Aug 2004 19:31:00 -0000 [thread overview] Message-ID: <20040822193135.15044.qmail@sourceware.org> (raw) In-Reply-To: <20040812163817.17005.jerrydy@sbcglobal.net> ------- 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
next prev parent reply other threads:[~2004-08-22 19:31 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-08-12 16:38 [Bug c++/17005] New: " jerrydy at sbcglobal dot net 2004-08-12 17:23 ` [Bug c++/17005] " pcarlini at suse dot de 2004-08-12 17:26 ` [Bug libstdc++/17005] " pcarlini at suse dot de 2004-08-12 17:39 ` jbuck at gcc dot gnu dot org 2004-08-12 17:53 ` jbuck at gcc dot gnu dot org 2004-08-12 18:10 ` pcarlini at suse dot de 2004-08-12 18:29 ` jerrydy at sbcglobal dot net 2004-08-12 18:33 ` jbuck at gcc dot gnu dot org 2004-08-12 20:29 ` jerrydy at sbcglobal dot net 2004-08-12 22:09 ` danglin at gcc dot gnu dot org 2004-08-13 2:11 ` jerrydy at sbcglobal dot net 2004-08-13 4:40 ` danglin at gcc dot gnu dot org 2004-08-14 18:16 ` dave at hiauly1 dot hia dot nrc dot ca 2004-08-14 18:31 ` pcarlini at suse dot de 2004-08-14 19:03 ` cvs-commit at gcc dot gnu dot org 2004-08-14 19:27 ` pinskia at gcc dot gnu dot org 2004-08-14 19:45 ` dave at hiauly1 dot hia dot nrc dot ca 2004-08-15 18:06 ` pcarlini at suse dot de 2004-08-15 19:53 ` dave at hiauly1 dot hia dot nrc dot ca 2004-08-15 20:06 ` pcarlini at suse dot de 2004-08-15 20:47 ` dave at hiauly1 dot hia dot nrc dot ca 2004-08-15 22:29 ` dave at hiauly1 dot hia dot nrc dot ca 2004-08-21 10:26 ` pcarlini at suse dot de 2004-08-22 17:35 ` pcarlini at suse dot de 2004-08-22 19:31 ` dave at hiauly1 dot hia dot nrc dot ca [this message] 2004-08-25 17:50 ` cvs-commit at gcc dot gnu dot org 2004-08-25 18:08 ` pinskia at gcc dot gnu dot org 2005-01-31 16:39 ` pcarlini at suse dot de 2005-02-02 13:26 ` hundertmarck at boehme-weihs dot de 2005-02-02 13:30 ` pcarlini at suse dot de 2005-02-02 15:28 ` dave at hiauly1 dot hia dot nrc dot ca 2005-02-08 19:58 ` hundertmarck at boehme-weihs dot de 2005-03-01 10:43 ` hundertmarck at boehme-weihs dot de 2005-03-01 11:01 ` pcarlini at suse dot de 2005-03-01 11:12 ` hundertmarck at boehme-weihs dot de 2005-03-01 15:06 ` dave at hiauly1 dot hia dot nrc dot ca
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040822193135.15044.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).