Eric Blake byu.net> writes:
> Here's spin two of the patch. It turns out that doing one shell loop per
> header also allows us to fold in platform-specific inclusion requirements.
>
...
> Some of our unit tests never use large files, so rather than drag
> in a dependency on fseeko, they should
According to Bruno Haible on 1/9/2010 8:53 AM:
> Eric Blake wrote:
>> Here's spin two of the patch.
>
>> [PATCH 1/4] warn-on-use: new module
>> ...
>> + supported by the compiler. If the compiler does not support this
>> + feature, the macro expands to an unused typedef declaration.
>
> It's
Eric Blake wrote:
> Here's spin two of the patch.
> [PATCH 1/4] warn-on-use: new module
> ...
> + supported by the compiler. If the compiler does not support this
> + feature, the macro expands to an unused typedef declaration.
It's now an 'extern' declaration, so I would change
"unused type
According to Eric Blake on 1/1/2010 7:24 AM:
>> I would prefer an implementation where the expansion of
>> gl_WARN_ON_USE_PREPARE([locale.h], [setlocale])
>> does not depend on other invocations of gl_WARN_ON_USE_PREPARE, even if it
>> leads to a larger 'configure' file.
>
> OK, I'll work on ref
Hi Eric,
> I'm glad you liked my approach at poisoning those identifiers.
Sure! I didn't know how to do it; you found the approach :-)
> By the way, is there any reason we don't have an fpclassify
> module yet?
It's rarely used in math function algorithms: Hardly any algorithm
needs to disting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 1/1/2010 7:11 AM:
> The recommendation how to deal with variables like 'environ':
>
> static inline char ***rpl_environ (void) { return &environ; }
> # define environ (*rpl_environ ())
>
> will not work when a program
Hi Eric,
Eric Blake wrote:
> I won't push this until it's had a bit longer for reviews.
Yes, for reviewing 4 patches like this you need to give me a day at least.
> [1/4] warn-on-use: new module
The recommendation how to deal with variables like 'environ':
static inline char ***rpl_env
I've learned my lesson from this morning - I won't push this until it's had a
bit longer for reviews. At any rate, this introduces warn-on-use, then
demonstrates three distinct ways to use it. I am still working on the global
change of all remaining uses of GL_LINK_WARNING over to _GL_WARN_ON_
