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
On 12/18/2013 06:09 AM, Eric Blake wrote:
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.
I actually
On Wed, Dec 18, 2013 at 06:09:40AM -0700, Eric Blake wrote:
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
On 12/18/2013 06:25 AM, Martin Kletzander wrote:
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
On Wed, Dec 18, 2013 at 06:09:40AM -0700, Eric Blake wrote:
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
On Wed, Dec 18, 2013 at 06:34:43AM -0700, Eric Blake wrote:
On 12/18/2013 06:25 AM, Martin Kletzander wrote:
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'
