Re: a bunch of warnings

[Daniel J S. <dan...@ie...>]

On 08/28/2012 10:46 AM, sfeam (Ethan Merritt) wrote:
> On Monday, 27 August 2012, Daniel J Sebald wrote:
>>> "../term/emf.trm", line 344: warning: initializer does not fit or is
>>> out of range: -5
>>>
>>> EAM: This one is a true hit, however.
>>>        It looks to me that a dozen or so of the declarations at the
>>>        top of emf.trm are marked "unsigned" for no good reason.
>>>        But why only complain about this one and not 10 others?
>>
>> The others look to be set to valid unsigned numbers, e.g., 0, 1, FALSE,
>> TRUE, 0x2222, EMF_COLORS (which is 15), etc.  LT_UNDEFINED (which is -5)
>> is the only signed value.
>
> The others are valid at initialization time, but still may be
> assigned one of the flag values (e.g. LT_UNDEFINED) when the
> code is run.  If you run "grep LT_ emf.trm" you'll see many such cases.
> Since LT_UNDEFINED is known at compile time, I'm surprised that
> the compiler doesn't also complain about these other assignments.

True, but what is in term_api.h is a set of definitions, not an 
enumeration.  Only in the latter does the compiler know what the valid 
assignment could be.  An enumeration would be good, but that is too much 
shaking the tree this near to a release.


> The assignment of octal values to a (char) is not an error no matter
> what the signedness of (char), so that set of warnings is spurious and
> I won't change the code in gplt_x11.c or elsewhere.

Not sure.  I tried searching the Internet for a reference, but there is 
so much static from people wondering how to print/read hexadecimal 
values in C that I can't find anything.

The problem is that statement implies that hexadecimal values (i.e., 
representations) are inherently unsigned, which I'm not sure.  For 
example, 0xFE is a valid representation in C compilers.  Is -0xFE?  If 
so, then 0xFE means 254 and -0xFE means -254.  In the execution of the 
code, the assignment of a hexadecimal is just a byte transfer, but how 
the compiler interprets the abstract representation might be something 
different.


>> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
>> or is it the $ is not a valid character
> The $ is valid (and very common) in VAX/VMS identifiers.
> This whole section of code is inside #ifdef VMS so non-VAX compilers
> should not even be looking at it.

Yes, from what I remember, this should be ignored.  The compiler might 
have some internal test order wrong.

Dan