Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!fas.ri.cmu.edu!dstewart From: dstewart@fas.ri.cmu.edu (David B Stewart) Newsgroups: comp.unix.wizards Subject: Re: unsigned sizeof() Message-ID: <7980@pt.cs.cmu.edu> Date: 14 Feb 90 18:30:37 GMT References: <6042@arctic.nprdc.arpa> Organization: Carnegie-Mellon University, CS/RI Lines: 283 In article <6042@arctic.nprdc.arpa> stanonik@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@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@adm.BRL.MIL> <2548@auspex.auspex.com> Organization: Carnegie-Mellon University, CS/RI Newsgroups: alt.peeves Subject: Re: Not bad. Keywords: Distribution: alt References: <13229@boulder.Colorado.EDU> Organization: Carnegie-Mellon University, CS/RI In article <626351616.24300@minster.york.ac.uk> alanb@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@minster.york.ac.uk> Organization: Carnegie-Mellon University, CS/RI In article <626351616.24300@minster.york.ac.uk> alanb@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@shemp.CS.UCLA.EDU> <961@abvax.UUCP> <836@trlluna.trl.oz> <18742@watdragon.waterloo.edu> Organization: Carnegie-Mellon University, CS/RI In article <18742@watdragon.waterloo.edu> abrodnik@watdragon.waterloo.edu (Andrej Brodnik (Andy)) writes: >In article <836@trlluna.trl.oz> aurie@rhea.trl.oz.au.trl.oz (Alistair Urie - Radio and Satellite Networks) writes: >>>In article <29160@shemp.CS.UCLA.EDU> cshen@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@stealth.acf.nyu.edu> <7848@pt.cs.cmu.edu> <2212.21:08:11@stealth.acf.nyu.edu> <131446@sun.Eng.Sun.COM> Organization: Carnegie-Mellon University, CS/RI In article peter@ficc.uu.net (Peter da Silva) writes: >In article <131446@sun.Eng.Sun.COM> lm@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. . >/ \ >\_.--._/ 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@arctic.nprdc.arpa> stanonik@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@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@arctic.nprdc.arpa> Organization: Carnegie-Mellon University, CS/RI In article <6042@arctic.nprdc.arpa> stanonik@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@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