This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Problems with evolving feature test macros?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 11 Mar 2014 17:14:17 +0000
- Subject: Re: Problems with evolving feature test macros?
- Authentication-results: sourceware.org; auth=none
- References: <CAKgNAki3SzAN8rZjvMQxbqDkpRGBzsmNGBKMJ0DDcMAG0nG8gQ at mail dot gmail dot com> <531F34C8 dot 9000500 at cs dot ucla dot edu> <CAKgNAkj5Bn8oSEPcpoiw6HnoE6hoNkHP6VAZBt2h5z4UPDAeDA at mail dot gmail dot com>
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. 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.
--
Joseph S. Myers
joseph@codesourcery.com