Re: Fun with VMS, TBOOLEAN, macro definitions and DECC

[<ha...@on...>]

On Tue, May 04, 2004 at 01:18:17PM +0200, Hans-Bernhard Broeker wrote:
> On Mon, 3 May 2004, Lucas Hart wrote:
> > On Mon, May 03, 2004 at 05:48:58PM -0700, Ethan Merritt wrote:
> 
> > > %%%%%%%%% Unhappy TBOOLEANs
> > > 
> > > $ cc /DEFINE=(NO_GIH,HAVE_CONFIG_H,DECCRTL)/INCLUDE=[-]/PREFIX=ALL axis.c
> > > 
> > >     TBOOLEAN checkrange;
> > > .............^
> > > %CC-W-PROMOTMATCHW, In the definition of the function "axis_unlog_interval",
> > > the promoted type of checkrange is incompatible with the type of the corresponding
> > > parameter in a prior declaration.
> 
> I never used VMS to build any programs, but I take it this is a warning,
> not an error message, right?  Do we have reason to believe it actually
> breaks anything?
> 

(I no longer have access to a DEC Unix/Tru64 system - wouldn't be 
surprised to get the same warning messages with the DEC/Compaq C 
compiler there as well.)

The TBOOLEAN PROMOTMATCHW warnings are just warnings about a 
difference between the default promoted type for a parameter 
in the old-style function definition (int in this case) and 
its type in the new style function prototype (here TBOOLEAN)
which overrides the former. Innocuous, so I now disable the 
warning, e.g.   CC/WARN=DISABLE=(PROMOTMATCHW)

> 
> > My understanding is that C99 types _Bool as unsigned int, 
> > which DECC appears to expect.
> 
> C99 types it as a new atomic data type.  It's an integer data type, 
> but there's no particular reason whatsoever to assume it should be 
> as large as an entire int.  That would be quite wasteful, after all.
> 
> I'm quite sure DECC expects neither unsigned int nor char here --- 
> C99 is a non-existant concept in its view of the world.
> 

Depends on the version (equating Compaq C and DECC); v6.4, in 2001,
added support for C99 including an 8-bit _Bool data type and a 
/STANDARD=C99 flag.

However, I misinterpreted the reason for a lack of PROMOTMATCHW
when TBOOLEAN was declared as unsigned int;  unrelated to _Bool
but rather to the default promotion of the respective function 
parameters to int.

> [Function-like macro missing do { } while(0) bracket]
> > A simpler fix is 
> >   if (something) {
> >     PRINT0(...); 
> >   } else if (something) {
> >     PRINT1(...);
> >   }
> 
> That's not exactly a fix, but rather a kludgy workaround for a broken
> macro.  Since the macro is our own, we don't need that --- we can fix 
> the real problem.
> 

Agreed - the macro can be fixed; my point was intended to be that 
a simple kludge is sufficient for the one instance that the long-
established macro fails in the current source, without any functional
changes which might require more extensive testing.

-- Lucas Hart                         <ha...@on...>