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.