Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP Path: utzoo!linus!vaxine!wjh12!genrad!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!chris From: chris@umcp-cs.UUCP Newsgroups: net.unix-wizards,net.lang.c,net.bugs.4bsd Subject: Re: unsigned char -> unsigned int conversion Message-ID: <7528@umcp-cs.UUCP> Date: Mon, 18-Jun-84 00:14:03 EDT Article-I.D.: umcp-cs.7528 Posted: Mon Jun 18 00:14:03 1984 Date-Received: Wed, 20-Jun-84 00:52:07 EDT References: <183@haddock.UUCP> <778@bbncca.ARPA> Organization: Univ. of Maryland, Computer Science Dept. Lines: 50 While testing the assertion that ``unsigned char'' types propagate the ``unsigned''ness into expressions, I discovered something very interesting in the 4.1BSD (PCC) C compiler. The compiler emits ``.long''s in the assembly output! Here's a sample: unsigned char foo = 1; main() { if ((-1 | foo) > 0) printf("hi there\n"); } PCC output (slightly edited): .data .globl _foo _foo: .long 0x1 .data 1 L19: .ascii "hi there\12\0" .text .align 1 .globl _main _main: .word L13 movzbl _foo,r0 bisl2 $-1,r0 jeql L17 pushl $L19 calls $1,_printf L17: ret .set L13,0x0 .data Further experimentation shows that all ``static'' variables, and all initialized variables, are generated with a minimum size of 4 bytes. This apparently includes arrays as well (but ``char c[8]'' doesn't generate 32 bytes). I guess PCC is trying to keep things longword-aligned. As to the original point, we can see from the ``jeql'' (as opposed to ``jgtr'') that PCC *does* propagate the unsigned attribute. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland