[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110713140002.GD16618@brightrain.aerifal.cx>
Date: Wed, 13 Jul 2011 10:00:02 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: cluts review
On Wed, Jul 13, 2011 at 05:54:23PM +0400, Solar Designer wrote:
> > But thanks for the patch. Anyway, here:
> > https://github.com/lmarcetic/cluts/commit/7c836ff779c1f9ffecdae9f7d469772e88d3bc68
>
> OK. Why the "#define _POSIX_C_SOURCE 200809L //sigaction" vs. "#define
> _XOPEN_SOURCE //sigaction" inconsistency, though? I think _XOPEN_SOURCE
> is a safer bet here.
I would really put this in the makefile for consistency. In principle,
the values of feature test macros could lead to different versions of
certain functions being used, possibly even with different
interfaces/ABI, and cause problems with linking together object files
compiled with different settings.
The default with no feature test macro defined is not "_GNU_SOURCE" or
"variety bag". In principle it's supposed to be pure C, and in reality
it varies a lot and you shouldn't rely on it. Especially proprietary
unices, but also GNU, like to expose their traditional non-conformant
versions of certain functions (e.g. strerror_r) when no feature test
macro is present, which is a major issue for testing.
> And I generally avoid C++ comments in C source
> files, even though this became legal in C99 (and many C compilers
> recognized C++ comments before then). If we enable/require C99 anyway,
> this is a non-issue, and perhaps I am too old-fashioned. ;-) Testing
> cluts on some older systems could make sense, though - not so much to
> test those systems' libc's, but rather to better test cluts itself.
I think it's pretty hard to test functions that are part of a standard
that depends on and includes C99, while not requiring a (mostly)
C99-supporting compiler. I do tend to think // comments look "lazy",
but it's not a big deal either way.
> > Why do you think *snprintf and *asprintf aren't portable?
>
> They just are less portable than older functions such as sprintf().
> In practice, I think *snprintf() are portable enough these days and for
> this specific application, so your use of vsnprintf() is fine (although
> calling it with "NULL, 0" is a stress-test). asprintf() may or may not
> be portable enough depending on what systems cluts is meant to run on.
snprintf is C99 and POSIX and I think it's pretty reasonable to rely
on it. Legacy systems can implement it as a hideous wrapper for
tmpfile(), fprintf(), and fread() if they're not willing to fix their
libcs. :-)
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
