Jim Meyering wrote:
> vasnprintf.c uses variables named exp and remainder, and they shadow
> math functions. This poses a problem for me, since coreutils' "make
> distcheck" requires a clean build with -Werror -Wshadow.
Ouch. It's a pity that "gcc -Wshadow" has a useful part (when it warns about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding bug-findutils]
According to James Youngman on 5/16/2008 3:39 PM:
| On Fri, May 16, 2008 at 12:19 PM, Heinrich Mislik
| <[EMAIL PROTECTED]> wrote:
|> After reading the comments in stdbool.h I came to the same conclusion
|> and to the same fix.
vasnprintf.c uses variables named exp and remainder, and they shadow
math functions. This poses a problem for me, since coreutils' "make
distcheck" requires a clean build with -Werror -Wshadow.
Bruno, any objection to this change?
>From a492d243a5d6359642e94abea4b292f86a07caa5 Mon Sep 17 00:00:0
On Fri, May 16, 2008 at 12:19 PM, Heinrich Mislik
<[EMAIL PROTECTED]> wrote:
> After reading the comments in stdbool.h I came to the same conclusion
> and to the same fix. After that -iregex was completly broken. I found
> one second place, that needs the same change:
Which versions of gnulb are a
Heinrich Mislik wrote:
> Attached find the relevant parts from config.log.
Thank you. It shows the known AIX compiler bug that is explicitly tested
for in stdbool.m4. So the test is expected to fail. Nothing wrong here.
Bruno
On 15 May 2008 at 20:39, Eric Blake wrote:
> Heinrich Mislik univie.ac.at> writes:
>
> Hello Heinrich, and thanks for the report.
>
> > here is a problem with stdbool.h from gnulib:
> > pbool(256);
>
> Inherently non-portable when attempted with a C89 compiler. And
> Gnulib's
> replacem
Simon Josefsson <[EMAIL PROTECTED]> writes:
>>> Another way of looking at this is that
>>> there is a memory leak in the gnulib 'getpass' module.
>>
>> It's hard to argue this way: getpass() is not specified by a standard.
>
> It is a memory leak regardless of whether it is standardized.
It is de
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> This makes the gnulib 'getpass' module (not the 'getpass-gnu' module)
>> rather difficult to use: how do you know whether to de-allocate the
>> returned string or not? It depends on whether the system function or
>> the gnulib r
Simon Josefsson wrote:
> This makes the gnulib 'getpass' module (not the 'getpass-gnu' module)
> rather difficult to use: how do you know whether to de-allocate the
> returned string or not? It depends on whether the system function or
> the gnulib replacement was used.
Good point.
> Another way
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I noticed that a significant difference between other getpass
> implementations and glibc/gnulib's is that the latter allocate the
> output buffer.
Sorry, that is false: I just now noticed the 'static' modified in the
getpass.c code This makes it
I noticed that a significant difference between other getpass
implementations and glibc/gnulib's is that the latter allocate the
output buffer.
This makes the gnulib 'getpass' module (not the 'getpass-gnu' module)
rather difficult to use: how do you know whether to de-allocate the
returned string
11 matches
Mail list logo
