Re: [9fans] another compiler bug (another try to send this coherently)

Re: [9fans] another compiler bug (another try to send this coherently)

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 140 bytes --]

i thought that was one of the areas where the rules had changed with ANSI C
and assumed ken thompson had implemented the rules he knew!


[-- Attachment #2: Type: message/rfc822, Size: 1852 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] another compiler bug (another try to send this coherently)
Date: Tue, 17 Jul 2001 15:16:38 GMT
Message-ID: <3B544A97.5F5EA6E1@null.net>

Mike Haertel wrote:
> The unsigned char is _supposed_ to be promoted to signed int.

That is true, and I'm surprised that the compiler would get it
wrong.  One wonders where else the integer promotions aren't
done right.

Re: [9fans] another compiler bug (another try to send this coherently)

[Douglas A. Gwyn]

forsyth@vitanuova.com wrote:
> i thought that was one of the areas where the rules had changed with ANSI C
> and assumed ken thompson had implemented the rules he knew!

That would certainly account for it.
Note that "rules had changed" is a bit of an overstatement;
there was some uncertainty in that area, and different
implementors had done it differently, so we had to decide
what the rules should be.  The argument that preserving
valued rather than signedness of type was less apt to lead
to silent surprises won out.  It is true that previous AT&T
(Bell Labs) compilers had done it the other way around.
There is no need to reopen the argument now (personally I
would have preferred a third alternative).

Re: [9fans] another compiler bug (another try to send this coherently)

[Douglas A. Gwyn]

Mike Haertel wrote:
> The unsigned char is _supposed_ to be promoted to signed int.

That is true, and I'm surprised that the compiler would get it
wrong.  One wonders where else the integer promotions aren't
done right.

Re: [9fans] another compiler bug (another try to send this coherently)

[Boyd Roberts]

From: "Mike Haertel" <mike@ducky.net>
> I'm not actually trying to do anything that depends on this.
> I have been writing some high-performance AES (Rijndael) encryption
> routines lately.

yeah, i know what AES is.

> I decided the portability problems associated
> with relying on compilers getting the ANSI C rules exactly right
> were too much of a headache, so I went through the code to put in
> explicit casts anywhere implicit conversions would otherwise occur,
> to prevent broken compilers (like 8c) from doing the Wrong Thing.

ahh, that little tin god efficiency.  why didn't you _write_ the
code that way in the first place?

> I was reviewing my code, with the help of "8c -t" to print the
> parse trees and make sure there were no implicit promotions left,
> when I stumbled across a few more I had overlooked, and noticed
> moreover that 8c was inserting "CAST UINT" in places where ANSI
> says it should have inserted "CAST INT".  So I reported it as a bug.

don't you think that posting the above paragraph would have more
useful?

> It wasn't causing me any trouble,

it did, by your own admission.

> but I think these things should be fixed whenever you find them.

sure, but, i'm not sure plan 9 gets it _wrong_.

doug will probably disagree, but i know why.  i guess the ANSI
reasoning went:

    chars get promoted to int.  trouble is that whether they
    where signed or not was undefined,  so they all got
    promoted to int.

i think this is wrong.  they should have preserved their
unsigned property if they were declared as unsigned.  in
a char decl, well make a choice:

    - make it implementation dependant
    - declare 'em to be signed by definition

language law -- i hate it.

Re: [9fans] another compiler bug (another try to send this coherently)

[Mike Haertel]

>> Whatever it prints, it should print the same number twice,
>> not two different values.
>
>obviously the unsigned char is _not_ being promoted to signed int.
>
>just _what_ are you trying to do?

The unsigned char is _supposed_ to be promoted to signed int.

I'm not actually trying to do anything that depends on this.
I have been writing some high-performance AES (Rijndael) encryption
routines lately.  I decided the portability problems associated
with relying on compilers getting the ANSI C rules exactly right
were too much of a headache, so I went through the code to put in
explicit casts anywhere implicit conversions would otherwise occur,
to prevent broken compilers (like 8c) from doing the Wrong Thing.

I was reviewing my code, with the help of "8c -t" to print the
parse trees and make sure there were no implicit promotions left,
when I stumbled across a few more I had overlooked, and noticed
moreover that 8c was inserting "CAST UINT" in places where ANSI
says it should have inserted "CAST INT".  So I reported it as a bug.

It wasn't causing me any trouble, but I think these things should
be fixed whenever you find them.  Somewhere down the road it'll
save some poor sot from hours of head scratching when attempting
import something with pcc.

Re: [9fans] another compiler bug (another try to send this coherently)

[Boyd Roberts]

From: "Mike Haertel" <mike@ducky.net>
> Whatever it prints, it should print the same number twice,
> not two different values.

obviously the unsigned char is _not_ being promoted to signed int.

just _what_ are you trying to do?

Re: [9fans] another compiler bug (another try to send this coherently)

[Mike Haertel]

>Mike Haertel wrote:
>> On a conforming implementation with 32-bit ints, this
>> program should print "-1 -1".
>>         static unsigned char tab[1] = { 0x80 };
>>         static int x = 0x80;
>>         printf("%d %d\n", tab[0] << 24 >> 31, x << 24 >> 31);
>
>How do you figure that?  The promoted tab[0] (signed int) or x
>left-shifted 24 places sets the sign bit, and right-shifting a
>negative value is implementation-defined.

Sorry, my mistake.

Whatever it prints, it should print the same number twice,
not two different values.

Re: [9fans] another compiler bug (another try to send this coherently)

[Boyd Roberts]

oops, that last missive was meant for rog.

damn trackpad.

Re: [9fans] another compiler bug (another try to send this coherently)

[Boyd Roberts]

do you define implementation as the compiler or the
whole system?  the other guy seems to be doing stupid
stuff with APE or some ANSI (ie. non native plan 9
compiler [ken C]):

#include <stdio.h>
#include <stdlib.h>

int
main()
{
static unsigned char tab[1] = { 0x80 };
static int x = 0x80;

printf("%d %d\n", tab[0] << 24 >> 31, x << 24 >> 31);
exit(EXIT_SUCCESS);
}

why he just can't read the doc and stop fucking with stupid
shifts is beyond me?  is this C programming 101?

i would class the compiler as the implementation, 'cos
you could have multiple compilers (and you do) on plan 9
or on some random unix you could have the native compiler
and then install gcc (god forbid).

i tend to err on the side of caution (ie. paranoia/overkill)
so i don't bitten by such glop.

Re: [9fans] another compiler bug (another try to send this coherently)

[Boyd Roberts]

From: <rog@vitanuova.com>
> implementation-defined implies the result is at least consistent across
> a particular implementation.

care to re-read that?

Re: [9fans] another compiler bug (another try to send this coherently)

[rog]

> How do you figure that?  The promoted tab[0] (signed int) or x
> left-shifted 24 places sets the sign bit, and right-shifting a
> negative value is implementation-defined.

implementation-defined implies the result is at least consistent across
a particular implementation.  the example that was given shows that
that isn't the case (if the unsigned char is indeed being promoted to
signed int, which it isn't, as the compiler error messages for the
following code imply:)

#include <u.h>
#include <libc.h>

int
main(void)
{
         static unsigned char tab[1] = { 0x80 };
	char *z;
	z = tab[0] << 24 >> 31;
}

Re: [9fans] another compiler bug (another try to send this coherently)

[Boyd Roberts]

>         printf("%d %d\n", tab[0] << 24 >> 31, x << 24 >> 31);

i really don't understand what the problem is here.  it's
very simple (not that i have a copy of k&r 2 or the
standard with me).

shifting stuff:

    - verify what you're shifting [signed/unsigned]
    - if it's signed, watch out for setting the sign bit
    - shifts that cause over/under-flow may ruin your
      whole day
    - when in doubt, _read_ the doc

if you'd like to see some bit mangling code, read:

    http://www.planete.net/~boyd/code/des.msg

Re: [9fans] another compiler bug (another try to send this coherently)

[Douglas A. Gwyn]

Mike Haertel wrote:
> On a conforming implementation with 32-bit ints, this
> program should print "-1 -1".
>         static unsigned char tab[1] = { 0x80 };
>         static int x = 0x80;
>         printf("%d %d\n", tab[0] << 24 >> 31, x << 24 >> 31);

How do you figure that?  The promoted tab[0] (signed int) or x
left-shifted 24 places sets the sign bit, and right-shifting a
negative value is implementation-defined.

[9fans] another compiler bug (another try to send this coherently)

[Mike Haertel]

Argh, the wrong stuff got pasted on the last try and it included a ^D.

This program illustrates that the integral promotions
of types smaller than int will incorrectly promote unsigned
char to unsigned int, rather than signed int as required
by ANSI C.

On a conforming implementation with 32-bit ints, this
program should print "-1 -1".

#include <stdio.h>
#include <stdlib.h>

int
main()
{
	static unsigned char tab[1] = { 0x80 };
	static int x = 0x80;

	printf("%d %d\n", tab[0] << 24 >> 31, x << 24 >> 31);
	exit(EXIT_SUCCESS);
}