Re: Bug in C compiler Compiler Bug for Case 3411658RE (fwd)

[Paul Eggert]

"Belgardt, Wolfgang" <address@hidden> writes:

> This is this responds from c++ engineering:

Thanks for following up on this, but it appears that we're at a dead end.
It sounds like the C++ engineering team did not read my latest message
(enclosed below), as they did not respond to any of its points.

Until HP fixes the bug where Compaq C rejects the "bool e = &s" shown below,
most GNU software won't use Compaq C's implementation of the boolean data type.
Perhaps that's for the best, at least in the shorter term.
In the longer term HP can switch to GCC.


> From: Paul Eggert <address@hidden>
> Date: 28 Apr 2003 13:56:18 -0700
>
> > From: "Belgardt, Wolfgang" <address@hidden>
> > Date: Mon, 28 Apr 2003 16:19:28 +0200
> 
> > The construct at hand involves an initializer for an
> > object with static storage duration, so it is a
> > constraint that the expression be a constant expression
> > or a string literal.  Since it isn't a string literal,
> > it must be one of the "relaxed" forms of constant
> > expression enumerated in 6.6(7).  (_Bool)&foo is clearly
> > not a null pointer constant, an address constant, or
> > an address constant for an object type plus or minus
> > an integer constant expression.
> 
> There must be some confusion here, due to later discussion on the
> subject.  Let's go back to an extract from the original program that
> started this thread:
> 
>   #include <stdbool.h>
>   struct s { _Bool s: 1; _Bool t; } s;
>   bool e = &s;
> 
> There is no cast here, and the expression "&s" is clearly a constant
> expression, so it is valid C99.
> 
> > Since the address of an object with static storage duration is not
> > known until link time, producing the correct result requires that
> > the compare operation happen at link time or later.
> 
> Not in this case, since &s cannot possibly be zero.
> 
> > a compiler could simply evaluate the expression as 1 without
> > requiring any link-time or run-time evaluation.
> 
> Yes, that's correct.
> 
> > However, in the realm of practical considerations, it should be
> > noted that it is a common practice on some platforms to use weak
> > symbol references
> 
> Such practice is beyond the scope of the C99 standard.  Weak symbols
> are an extension to C99, and C99 compilers that support them as
> extensions can place extra restrictions on them.
> 
> In other words, a C99 compiler can prohibit "bool e = &s;" if "s" is a
> weak symbol reference, without violating the C99 standard, since one
> cannot declare a weak symbol in pure C99.  However, the program
> fragment quoted above must be accepted by any valid C99 compiler.