Re: GNU Diffutils 2.8 is available

[Albert Chin]

On Tue, Mar 26, 2002 at 02:06:18PM -0800, Paul Eggert wrote:
> > From: Albert Chin <address@hidden>
> > Date: Tue, 26 Mar 2002 14:37:37 -0600
> > 
> > On Tru64 UNIX with the Commercial C compiler (not the one from the
> > base OS), <stdbool.h> in /usr/include.dtk has:
> >   #define bool    _Bool
> > 
> > I have no idea what _Bool is
> 
> On many hosts _Bool is built into the compiler.

Is _Bool specific to C99?

> >   gmake[3]: Entering directory `/opt/build/diffutils-2.8/lib'
> >   cc -DHAVE_CONFIG_H -I. -I. -I.. -I../intl
> >   -I/opt/TWWfsw/libiconv17/include  -O2 -std1 -c `test -f exclude.c ||
> >   echo './'`exclude.c
> >   cc: Error: exclude.h, line 49: Missing ";". (nosemi)
> >   bool excluded_filename PARAMS ((struct exclude const *, char const *));
> >   -----^
> 
> Sorry, I don't understand the problem yet.  This compile doesn't use
> system.h or setmode.c, so it must be a problem with exclude.c alone.
> 
> Your proposed patch:
> 
> > --- lib/exclude.c.orig      Tue Mar 26 14:20:49 2002
> > +++ lib/exclude.c   Tue Mar 26 14:21:03 2002
> > @@ -24,11 +24,7 @@
> >  # include <config.h>
> >  #endif
> >  
> > -#if HAVE_STDBOOL_H
> > -# include <stdbool.h>
> > -#else
> >  typedef enum {false = 0, true = 1} bool;
> > -#endif
> >  
> >  #include <errno.h>
> >  #ifndef errno
> 
> indicates that your host has <stdbool.h> and that HAVE_STDBOOL_H
> is defined, but that '_Bool' does not work for some reason.  Is that
> correct?

Correct.

> I would rather not use a patch like the proposed one, partly because
> some hosts generate better code if "bool" is defined by the compiler,
> partly because they generate better diagnostics.  So I'd rather get
> to the underlying problem.  Perhaps the correct fix is to modify
> "configure" so that HAVE_STDBOOL_H is not defined on your platform.

Agreed.

> What is the output of this command?
> 
>   cc -E -DHAVE_CONFIG_H -I. -I. -I.. -I../intl \
>     -I/opt/TWWfsw/libiconv17/include -std1 exclude.c | grep excluded_filename

_Bool  excluded_filename  ( struct exclude const * , char const * ) ;
excluded_filename (struct exclude const *ex, char const *f)

> What happens when you compile and run the following little program,
> using "cc -std1"?  What is its exit status?
> 
>   #include <stdbool.h>
>   bool x;
>   bool y = false;
>   bool j = true;
>   int main (void)
>   {
>     return x + y + !j;
>   }

cc: Error: a.c, line 2: Missing ";". (nosemi)
bool x;
-----^
cc: Info: a.c, line 2: The _Bool keyword is not supported in this
language mode.  It will be treated as an identifier in this
compilation. (boolna)
bool x;
^
cc: Error: a.c, line 7: In this statement, "x" is not declared.
(undeclared)
return x + y + !j;
-------^
cc: Error: a.c, line 7: In this statement, "y" is not declared.
(undeclared)
return x + y + !j;
-----------^
cc: Error: a.c, line 7: In this statement, "j" is not declared.
(undeclared)
return x + y + !j;
----------------^

> What is the output of "cc -E -std1" on the same little program?

# 1 "a.c"
# 1 "/usr/include.dtk/__DECC_include_prologue.h"
#pragma __environment save
#pragma __environment header_defaults
# 1 "/usr/include.dtk/stdbool.h"
# 1 "/usr/include.dtk/__DECC_include_epilogue.h"
#pragma __environment restore
# 2 "a.c"
 _Bool  x;
 _Bool  y =  0 ;
 _Bool  j =  1 ;
int main (void)
{
return x + y + !j;
}

BTW, "-std" works fine. It's "-std1" that gives a problem. According
to cc(1):
  -std0
      Selects the K & R language mode. Enforces the K & R programming style,
      with certain ANSI extensions in areas where the K & R behavior is unde-
      fined or ambiguous. In general, -std0 compiles most pre-ANSI C89 pro-
      grams and produces expected results.  The -std0 option leaves the mac-
      ros __STDC__ and __STDC_VERSION__ undefined.

  -std1
      Selects the strict ANSI C89 language mode. Strictly enforces the ANSI
      C89 standard and all its prohibitions (such as those that apply to the
      handling of void types, the definition of lvalues in expressions, the
      mixing of integrals and pointers, and the modification of rvalues).

I think if we augmented the test of <stdbool.h> by using a test
program such as the above to test for success we'd be ok.

-- 
albert chin (address@hidden)