Re: [Bug libstdc++/17005] wide character strings don't work on HP

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)