This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with evolving feature test macros?


Joseph,

On Tue, Mar 11, 2014 at 6:14 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 11 Mar 2014, Michael Kerrisk (man-pages) wrote:
>
>> Really? I could imagine it to be a source of quite some pain for
>> programmers trying to write portable code, although I have no specific
>> examples to cite. The point here is that programmer's are trying to
>> write applications that are not Linux-specific, but are forced to
>
> Then they shouldn't be using qecvt.

Well, I was using qecvt() as an example of a more general phenomenon
with these FTM changes. It looks like it was not a good example (it
caught my eye because it was the nearest to hand in the initial
discussion of this work), but I still wonder if there might be a
general problem that these evolving FTM requirements may force
programmers to specify a more generous set of FTMs that they might
otherwise desire. However, I have no concrete examples.

Another question. Suppose we have some code that uses two interfaces
that (on older glibc) require, respectively, _SVID_SOURCE (or
_BSD_SOURCE) and _XOPEN_SOURCE. With the glibc 2.20 changes,
_SVID_SOURCE will generate a warning. On the other hand, specifying
just _DEFAULT_SOURCE won't work on older glibc versions. So, is the
the correct approach then that in all cases where _SVID_SOURCE or
_BSD_SOURCE was required, then _DEFAULT_SOURCE should be *added* (and
_BSD_SOURCE/_SVID_SOURCE retained), in order to produce source code
that compiles warning free across glibc versions?

> The whole ecvt/fcvt/gcvt function
> family is obsolete (the parts that were in POSIX as XSI extensions were
> marked LEGACY in the 2001 revision and removed in the 2008 revision), and
> qecvt never was even in POSIX.
>
> For a portable application, you should avoid interfaces removed in newer
> standard versions, and probably avoid non-POSIX interfaces (_SVID_SOURCE
> and _BSD_SOURCE never were particularly well-defined sets of interfaces,
> at least not recently when __USE_MISC covers lots of stuff that's neither
> BSD nor SVID, and certainly weren't portably available sets of
> interfaces).  An application using _POSIX_C_SOURCE=200809L is a lot more
> likely to be portable (although not having reviewed the conformtest
> expectations against that version of POSIX, it's likely there are bugs
> beyond those currently shown by conformtest).
>
> snprintf (not sprintf as suggested by the manpage) should be used instead
> of qecvt and the rest of that family.

Thanks. Fixed.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]