unsigned sizeof()

[David B Stewart]

In article <6042 at arctic.nprdc.arpa> stanonik at nprdc.navy.mil (Ron Stanonik) writes:
>We ran into a "feature" while porting a program to our 3B2/600G
>running sysV rel 3.2.2 V3: sizeof() returns unsigned.
>
>The code looked like
>
>	struct arf buf[MAX-1];
>	while ((cnt = read(fd, buf, sizeof(buf))) >= sizeof(buf[0])) {
>		do stuff with cnt arfs in buf
>	}
>
>The intent, apparently, is to reduce the number of reads by reading
>several arf structs at once.  The problem occurs when the read returns
>-1; since sizeof is unsigned the -1 is coerced into a big positive
>number.
>
>Yes, 2nd edition K&R says the result of sizeof is unsigned (though
>it also says the type is implementation-defined, p204, which I find
>contradictory).  Why though?  Why make sizeof unsigned?
>
>Sorry if this is old news.  It was a surprise to us; ie, sizeof
>on our suns and vax (4bsd) returns signed.
>
>Thanks,
>
>Ron Stanonik
>stanonik at nprdc.navy.mil
>ucsd!nprdc!stanonik
Newsgroups: comp.unix.wizards
Subject: Virtual Address Caching on Sun 3/260
Keywords: 
Distribution: 
Organization: Carnegie-Mellon University, CS/RI


Newsgroups: comp.unix.wizards
Subject: Re: vmunix: stropen: out of streams in SunOS 4.0 ??
Keywords: 
Distribution: 
References: <21119 at adm.BRL.MIL> <2548 at auspex.auspex.com>
Organization: Carnegie-Mellon University, CS/RI


Newsgroups: alt.peeves
Subject: Re: Not bad.
Keywords: 
Distribution: alt
References: <13229 at boulder.Colorado.EDU>
Organization: Carnegie-Mellon University, CS/RI



In article <626351616.24300 at minster.york.ac.uk> alanb at minster.york.ac.uk writes:
>
>There is a new book out called "Real-time Systems and their Programming
>Languages" which people might find interesting.
>Highlights of the book include (according to the back cover anyway!)
>		:
>		:
>  - A detailed comparison and evaluation of the major real-time languages:
>    Ada, Modula-2, and occam 2.
>		:
>		:
>The book is by Alan Burns and Andy Wellings, and it is published by
>Addison Wesley in their International Computer Science Series.
>It is about 600 pages in length and cost 19:95 (UK pounds).


What no C?  I don't care how 'real-time' you think C is, but it is
one of the most common languages for real-time systems ...

~dave
Newsgroups: comp.lang.ada,comp.lang.modula2,comp.sys.transputer,comp.realtime
Subject: Re: New Real-Time Systems Book
Keywords: 
Distribution: 
References: <626351616.24300 at minster.york.ac.uk>
Organization: Carnegie-Mellon University, CS/RI

In article <626351616.24300 at minster.york.ac.uk> alanb at minster.york.ac.uk writes:
>
>There is a new book out called "Real-time Systems and their Programming
>Languages" which people might find interesting.
>Highlights of the book include (according to the back cover anyway!)
>
>
>  - A detailed comparison and evaluation of the major real-time languages:
>    Ada, Modula-2, and occam 2.
>


What no C?  I don't care how 'real-time' you think C is, but it is
one of the most common languages for real-time systems ...

~dave
Newsgroups: comp.realtime
Subject: Re: Language constructs for interrupt facility
Keywords: 
Distribution: 
References: <29160 at shemp.CS.UCLA.EDU> <961 at abvax.UUCP> <836 at trlluna.trl.oz> <18742 at watdragon.waterloo.edu>
Organization: Carnegie-Mellon University, CS/RI

In article <18742 at watdragon.waterloo.edu> abrodnik at watdragon.waterloo.edu (Andrej Brodnik (Andy)) writes:
>In article <836 at trlluna.trl.oz> aurie at rhea.trl.oz.au.trl.oz (Alistair Urie - Radio and Satellite Networks) writes:
>>>In article <29160 at shemp.CS.UCLA.EDU> cshen at maui.cs.ucla.edu
>>>(Chien Chung Shen) writes:
>>>>I am interested in language constructs for interrupt facility.
>>>>Ada has "address clauses" and entry calls. Are there any other
>>>>languages which support interrupt facility and how are they
>>>>implemented? Any direction is appreciated.
>>>>
>>
>>I rather liked the way HP does it in there development systems, a $INTERRUPT
>>pre-complier command in the source sets the following routines as interupts
>>(in effect the routines compile to an RTI rather than RTS return - in 68K )
>
>Modula-2 has IOTRANSFER and the new BSI standard tries to specify it even more
>preceisley. It (Modula-2) assumes that interrupt routine is nothing else but
>another process. So interrupt handling is just a special case of general
>concept of process handling.
>
>Andrej

Newsgroups: comp.unix.wizards
Subject: Re: What new system calls do you want in BSD?
Keywords: 
Distribution: usa
References: <12157 at stealth.acf.nyu.edu> <7848 at pt.cs.cmu.edu> <2212.21:08:11 at stealth.acf.nyu.edu> <131446 at sun.Eng.Sun.COM> <MSM1E7xds13 at ficc.uu.net>
Organization: Carnegie-Mellon University, CS/RI

In article <MSM1E7xds13 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>In article <131446 at sun.Eng.Sun.COM> lm at sun.UUCP (Larry McVoy) writes:
>> Bottom line: threads without kernel support are largely useless.
>
>Which is one reason I want *clean* asynchronous I/O, in the form of
>some equivalent of my aread/awrite/await proposal.
>-- 
> _--_|\  Peter da Silva. +1 713 274 5180. <peter at ficc.uu.net>.
>/      \
>\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
>      v  "Have you hugged your wolf today?" `-_-'

----- News saved at 14 Feb 90 18:29:30 GMT
In article <6042 at arctic.nprdc.arpa> stanonik at nprdc.navy.mil (Ron Stanonik) writes:
>We ran into a "feature" while porting a program to our 3B2/600G
>running sysV rel 3.2.2 V3: sizeof() returns unsigned.
>
>The code looked like
>
>	struct arf buf[MAX-1];
>	while ((cnt = read(fd, buf, sizeof(buf))) >= sizeof(buf[0])) {
>		do stuff with cnt arfs in buf
>	}
>
>The problem occurs when the read returns -1; 
>since sizeof is unsigned the -1 is coerced into a big positive number.
>

I was not surprosed that sizeof() returned unsigned, but with your post I made
an amazing discovery.  If your code worked previously, I would assume
that 'cnt' was declared as a 'long'.  On the new machine, type "long" is
ignored, and treated as an 'int'.

As an example:

int i;
unsigned u;

	if (i < u) {}

is treated as

	if ((unsigned) i < u) {}

and not

	if (i < (long) u) {}

I would have suspected the last case, where the type long has precedence
over type unsigned.  Back to that
good ol' C reference book and here are the rules, in order:
(According to both K&R and Programming in C, by Stephen G. Kochan),

1. If either operand is of type float, then it is converted to double;
If either operand is of type char or short, it is converted to int;

2. If either operand is double, then all operands converted to double.

3. If either operand is long, then all operands converted to long.

4. If either is unsigned, then all operands converted to unsigned.

5. If none of above conversions performed, then all operands are of type int.


Look closely at number 3.  On all our modern 32-bit systems, long and int
are identical.  Even if you declare something as 'long', it will NOT
have precedence over rule 4.  Thus, throw out rule number 3.  
I have a feeling that for systems where sizeof(unsigned) != sizeof(long)  
rule 3 will still apply.

Followups have been set to comp.lang.c

~dave
-- 
David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, 
	Carnegie Mellon University,  email: stewart at faraday.ece.cmu.edu 
The following software is now available; ask me for details
        CHIMERA II, A Real-time OS for Sensor-Based Control Applications
Newsgroups: u3b.misc,comp.unix.wizards,comp.lang.c
Followup-To: comp.lang.c
Subject: Re: unsigned sizeof()
Keywords: 
Distribution: 
References: <6042 at arctic.nprdc.arpa>
Organization: Carnegie-Mellon University, CS/RI

In article <6042 at arctic.nprdc.arpa> stanonik at nprdc.navy.mil (Ron Stanonik) writes:
>We ran into a "feature" while porting a program to our 3B2/600G
>running sysV rel 3.2.2 V3: sizeof() returns unsigned.
>
>The code looked like
>
>	struct arf buf[MAX-1];
>	while ((cnt = read(fd, buf, sizeof(buf))) >= sizeof(buf[0])) {
>		do stuff with cnt arfs in buf
>	}
>
>The problem occurs when the read returns -1; 
>since sizeof is unsigned the -1 is coerced into a big positive number.
>

I was not surprosed that sizeof() returned unsigned, but with your post I made
an amazing discovery.  If your code worked previously, I would assume
that 'cnt' was declared as a 'long'.  On the new machine, type "long" is
ignored, and treated as an 'int'.

As an example:

int i;
unsigned u;

	if (i < u) {}

is treated as

	if ((unsigned) i < u) {}

and not

	if (i < (long) u) {}

I would have suspected the last case, where the type long has precedence
over type unsigned.  Back to that
good ol' C reference book and here are the rules, in order:
(According to both K&R and Programming in C, by Stephen G. Kochan),

1. If either operand is of type float, then it is converted to double;
If either operand is of type char or short, it is converted to int;

2. If either operand is double, then all operands converted to double.

3. If either operand is long, then all operands converted to long.

4. If either is unsigned, then all operands converted to unsigned.

5. If none of above conversions performed, then all operands are of type int.


Look closely at number 3.  On all our modern 32-bit systems, long and int
are identical.  Even if you declare something as 'long', it will NOT
have precedence over rule 4.  Thus, throw out rule number 3.  
I have a feeling that for systems where sizeof(unsigned) != sizeof(long)  
rule 3 will still apply.

Followups have been set to comp.lang.c

~dave
-- 
David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, 
	Carnegie Mellon University,  email: stewart at faraday.ece.cmu.edu 
The following software is now available; ask me for details
        CHIMERA II, A Real-time OS for Sensor-Based Control Applications