Hi Jonathan,
> On 22/01/21 12:04 +0100, Rainer Orth wrote:
>>why? I've just double-checked the OpenGroup pages: all of the functions
>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>have Technical Corrigenda applied. IIUC IEEE 1003.1-2017 is just a
>>revision of the -2008 standard, not a new issue (XPG8 or something).
>
> Technically, the 2008 standard has been withdrawn and replaced by
> 2017. Since the content is the same, it seems more correct to refer to
> the current standard (even if Solaris only documents support for the
> 2008 edition, if it also implements the corrigenda then it conforms to
> 2017 even if it doesn't document that).
I've found no macro that would distinguish P1003.1-2008 and -2017. It
seems both are identified by _XOPEN_SOURCE=700 and
_POSIX_C_SOURCE=200809L.
> But as I said, a shorter, more memorable name like "xpg7" or just
> "posix" might be preferable anyway.
I'd strongly prefer xpg7 over posix: after all, xpg6 systems are still
around (Solaris 11.3 being one of them, and I suspect older AIX versions
as well). It's certainly much less of a mouthful than ieee_1003.1-2008 ;-)
>>>> As for the BSD group, I suggest to have one representative configure
>>>> test (for localeconv_l perhaps) and then use an appropriate name for the
>>>> group as a whole. Again, this will most likely be an all-or-nothing
>>>> thing.
>>>
>>> I'm not sure this is really all-or-nothing for these. Maybe strtof_l and cie
>>> can be grouped by. But the 3 others are really different. Linux have
>>> wcsftime_l
>>> but not the others. AIX avec none. BSD have all.
>>
>>TBH, I don't care about Linux here: it will continue to use the gnu
>>variant anyway. Besides, since the patch will have to work on targets
>>without wcsftime_l and the other BSD functions, I don't see any harm in
>>not using one non-standard one of them although it's present.
>
> I agree that GNU/Linux will continue to use the gnu model, but it can
> still be usable as a useful extra test of the code's portablility,
> since it implements everything in XPG7 (and more). We shouldn't spend
> any effort doing linux-specific changes in this new model, since they
> won't be used in practice. But if it works "out of the box" with no
> tweaks, then that is useful for testing.
Absolutely: the more different implementation we can throw at the code,
the better for portability.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
