Conference 7.286::atarist

To assure the European registered developers :

I received also the upgrade mailing, the only difference is an extra 20$
for shipment costs. I guess I don't have to mention I returned it stante
pede to MWC. Curious how long it will take before it arrives over here.

Cor

My copy came today.  (Anyone want to buy it?). It consists of three
single-density floppies containing updates to the V2.* releases.  There
are manuals for the source language debugger and resource editor, and
a small document detailing changes and installation instructions.

Martin.

Here is my sample program that illustrates the bug:

main()
{
	int x;
	char y;
	x='\201';
	printf("%d\n", x);
	y='\201';
	printf("%d\n", y);
}

On VMS and Ultrix, both printf() statements print -127. 
On the ST, with Mark Williams C V3.0.6 the first statement 
prints 129 and the second one prints -127.  I ran into this 
when trying to make a program work on all three systems. 
I was using character constants having the 8th bit set as 
cases in a switch.  The cases became negative numbers on 
VMS and Ultrix and became positive numbers on the ST. 
This would have been OK if MWC was consistent and treated 
all items of type char as unsigned.  But as you can see, 
items of type char, except character constants, are as they 
should be - signed.

The workaround in my case is to specify the numbers as 
(0nnn-256).  So instead of '\201', I say (0201-256).
This expression yields the needed negative number on all 
systems while preserving somewhat the visibility of the 
octal representation.

    Roy,
    	what happens if you cast the constant, eg.
    	int x;
    	x=(char)'\201';
    
    	This assumes that the normal definition for type char is signed. In
    any case, check the definition of character constants in MWC. It is
    certainly valid for a compiler to define character constants as
    unsigned. If that is so, this is not a bug in MWC, but just a
    portability issue which will show up in other compilers. When porting
    the SNMP agents to Ultrix we ran into a similar thing. Apparently, on
    the Sun systems, '\201' expanded with no sign extension, but on Ultrix
    it did. Our solution was to define them as int constants,
    eg. 0x0081. If we defined 0x81, we got a sign extension. 
    
    I am going to check this on some other compilers on the ST, and see
    what they generate. I have Laser C, Aztec, and Prospero. I suspect that
    Laser will sign extend, and the other two will not.
    
    Jerry

Jerry,

I tried the (char) cast in the course of trying to figure out the problem. 
As I recall, it didn't help: 

	case (char)'\201': 
and
	case '\201': 
and
	case 129:

were equivalent.  

But the code in my switch expresion was generating -127, so I ended 
up executing the default instead of the case.

K&R ('78 edition) discusses on this issue on page 40.  It says that 
whether promotion of char to int sign extends is machine dependent.  
In my bug report I mention that it would have been OK if all char 
processing were treated as unsigned.  But the BUG here is that MWC 
claims to sign extend, and in fact does so in most instances.  However, 
in the case of character constants, it does not.  That's the bug.

K&R'78 goes on to say that any character in the machine's standard character 
set will never be negative.  Does the new 2nd edition retain that statement?
Characters in the GR set (accented letters, etc.) are, of course, treated 
as negative numbers if char is treated as signed.

The solution for portability seems to be to not use character constant 
values outside the range of 0 to 127, except if you really are going 
to use them only as characters, where sign and value do not matter.

    I checked the ANSI standard as to how it treats character constants. It
    is up to the implementation to decide whether a character constant sign
    extends or not. However, if MWC is inconsistent in its treatment of
    character constants, it is certainly a serious bug.
    Note that LASER C does sign extend:
    int x = '\201'; ==> -127
    int x = (unsigned char)'\201'; ==> 129
    In all cases where char is equivalent to signed char, then
    char x = '\201'; Should yield -127 when treated as an int (eg %d or
    switch(x) {
    	case 129:
    		This is not executed;
    		break;
    	case -127: 
    		This gets executed;
    		break;
    }
                                                                         
    In the case:
    unsigned char x = '\201';
    When x is expanded it should NOT sign extend.
    
    Because of this type of problem, in the ASN.1 parser for our SNMP
    agent, we added a set of macros which always expand correctly,
    regardless of the target implementation. Note that the ANSI standard
    does have some examples, such as: '\xFF' == -1. But it states that the
    implementation may define character constants as signed or unsigned. 

    Re: .3
    
    Your note intrigued me so I did some checking:
    
    switch( (char)x )
    
    seems to do what you want on MWC, and I suspect that this would
    work on ULTRIX and VMS as well.
    
    Note that changing your printf("%d\n", x); to printf("%d\n", (char)x);
    also seems to make it print -127 rather than 129.
    
    The interesting test was declaring z as an int, and then saying
    z = y;  the printf then showed z as -127.  This behaviour seems
    inconsistent, and should probably be reported.
    
    Of course the manual says chars will be sign extended, so the fact
    that the character constants aren't would also seem to be a bug.
    
    I suspect the problem is due to MWC not being fully ANSI compliant.
    The workaround is to put the following in your program:
    
    #define char unsigned char
    
    The ramifications of this bug are enormous!
    
    						-Dave

    Dave,
    	I recently acquired mwc, and immediately tried out the problem.
    Character variables do sign extend:
    char x = '\201';
    When x is used in the appropriate context, it will sign extend
    appropriately, but when '\201' is used as an integer constant, no sign
    extending occurs. Even casting it as unsigned char does not force the
    sign extension. The sign extending of constants has been a real problem
    for us in porting SNMP agents to various platforms because, on some,
    0xFF yields -1 on some systems (eg 0xFFFF), and on others it yields
    255. Personally, I would brefer that a constant NOT sign extend, but
    the problem is that when you want to compare a character variable with
    a constant, the variable does sign extend where the constant does.
    
    In this case:
    char x = '\201';
    	:
    if (x == '\201')
    	:
    
    The above case would yield a false (on MWC, I believe).
    
    Jerry 

    I wrote a test, compiled and executed on several c compilers, Megamax
    Laser C, Mark Williams C, Prospero C (this is an ANSI implementation),
    and VAX Ultrix. With the exception of Mark Williams C, the constant,
    '\201' when assigned to an integer, or when used as a constant was
    widened to decimal -127 (eg sign extended). In Mark Williams C (version
    3.06), the constant was not sign extended, and yielded decimal 129 in
    every context. 
    
    Context			Result-WMC	Result-All others
    int x = '\201'		129		-127
    printf("%d", '\201')	129		-127
    char x = '\201'		-127		-127
    In the above, the widening is done with variable x, not the constant.		
    
    switch(x) {   		
    	case '\201': /*1*/	1 if x is int 	Does not compile. The
    		:                               constant '\201' == -127.
    	case -127:   /*2*/      2 if x is char
    }
    
    I don't really consider this behavior a bug, but it does make writing
    portable programs rather difficult.