On 12/18/2013 02:35 AM, Martin Kletzander wrote: > When test-locking is enabled, CFLAGS have -Dbool=char, which makes Huh? bool should never be defined to char in CFLAGS; it should only be replaced if gnulib thinks the compiler is too old.

>> pipefd[bool] fail (obviously). Forcing the subscript to be bool by >> double negation fixes the build breaker. > > I don't get how this could possibly make a difference. The 'output' > variable is declared bool, and then only ever assigned 'false' or > 'true', which if bool is replaced by gnulib are still guaranteed to be 0 > and 1, so using it directly as an array index is still safe. > But the thing is that due to -Dbool=char the variable is declared char, not bool.

On 12/18/2013 02:35 AM, Martin Kletzander wrote: > When test-locking is enabled, CFLAGS have -Dbool=char, which makes Huh? bool should never be defined to char in CFLAGS; it should only be replaced if gnulib thinks the compiler is too old. > pipefd[bool] fail (obviously). Forcing the subscript to be bool by > double negation fixes the build breaker. I don't get how this could possibly make a difference. The 'output' variable is declared bool, and then only ever assigned 'false' or 'true', which if bool is replaced by gnulib are still guaranteed to be 0 and 1, so using it directly as an array index is still safe. > > Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com&gt; > --- > > Notes: > I still can't build with '--enable-test-locking' and I'm not sure this > is the proper way to fix it. Also, the code wasn't touched for > months, so I'm not pushing it as a build-breaker. NACK. I need more details about the actual failure you are seeing, but this is not the right patch.