mike@ISIDAPS5.UUCP (Mike Maloney) (08/02/88)
Dear C-Heavies,
Is the size of a (signed or unsigned) short integer guarenteed to
be two bytes? I need to manipulate and compare some unsigned ints
modulo 65536. It would be clean and convenient to just let the
machine handle my wrap-around from 0 to 0xffff and verse-vica.
The following works fine on my Xenix-386 machine, but is it portable?
Note that the default integer size is 4 bytes, so the expression 'u'
inside the printf's is being converted.
unsigned short u;
u = 0xffff;
u++;
printf("0x%x\n",u); ==> 0x0
u = 0;
u--;
printf("0x%x\n",u); ==> 0xffff
Note however:
u = 0xffff;
u + 1 != 0 ==> In the expression 'u + 1', 'u' is upwardly
converted to 4 bytes before adding 1.
but
(unsigned short)(u + 1) == 0
--
Mike Maloney "The nice thing about standards
Integral Systems, Inc. is that there are so many to
Lanham Maryland choose from" - Murphyearleh@eleazar.dartmouth.edu (Earle R. Horton) (08/02/88)
In article <214@ISIDAPS5.UUCP> mike@ISIDAPS5.UUCP (Mike Maloney) writes: >Dear C-Heavies, > >Is the size of a (signed or unsigned) short integer guarenteed to >be two bytes? I need to manipulate and compare some unsigned ints >modulo 65536. It would be clean and convenient to just let the >machine handle my wrap-around from 0 to 0xffff and verse-vica. No. I have seen at least one compiler where sizeof(short) is one byte. About the only thing you can count on is that it is no larger than an int. You might be safe in 95% of cases in assuming that a short is shorter than a long, but I don't recommend even this assumption. Earle R. Horton. H.B. 8000, Dartmouth College, Hanover, NH 03755
drc@claris.UUCP (Dennis Cohen) (08/02/88)
In article <214@ISIDAPS5.UUCP> mike@ISIDAPS5.UUCP (Mike Maloney) writes: >Is the size of a (signed or unsigned) short integer guarenteed to >be two bytes? I need to manipulate and compare some unsigned ints >modulo 65536. It would be clean and convenient to just let the >machine handle my wrap-around from 0 to 0xffff and verse-vica. > Sorry, but the answer is "No". As a matter of fact, it can't even be guaranteed between compilers for the same piece of iron. An example is the Megamax C compiler for the Mac (and I think the Amiga as well) defines a short to be 8 bits, an int to be 16, and a long is 32; the other four compilers that I've used on the Mac define a short to be 16 bits. The only thing that is supposed to be guaranteed is: sizeof(short) <= sizeof(int) <= sizeof(long) You might even find some where they're all the same size (I seem to recall a compiler for CP/M which did that). Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/02/88)
In article <214@ISIDAPS5.UUCP> mike@ISIDAPS5.UUCP (Mike Maloney) writes: | Dear C-Heavies, | | Is the size of a (signed or unsigned) short integer guarenteed to | be two bytes? I need to manipulate and compare some unsigned ints | modulo 65536. It would be clean and convenient to just let the | machine handle my wrap-around from 0 to 0xffff and verse-vica. Shorts are at least two bytes, but may be longer, and bytes are at least eight bits but may be more, such as 9 on a 36 bit machine (PDP10, Honeywell), or 12 (some DEC machine with 12 bit words). -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
brb@akgua.ATT.COM (Brian R. Bainter) (08/03/88)
From article <214@ISIDAPS5.UUCP>, by mike@ISIDAPS5.UUCP (Mike Maloney): > Dear C-Heavies, > > Is the size of a (signed or unsigned) short integer guarenteed to > be two bytes? I need to manipulate and compare some unsigned ints > modulo 65536. It would be clean and convenient to just let the > machine handle my wrap-around from 0 to 0xffff and verse-vica. I had always thought that short integers were always 16 bits (due I suppose to my use of the language on a limited number of machines no doubt). So when I saw your question, I decided to do some checking, and sure enough on page 34 of K&R I was once again proven mistaken. On a Honeywell 6300 a short is 36 bits. I also noticed that everything except bytes and doubles were 36 bits. This is probably (and someone correct me if I'm wrong - I have all the confidence that you will) due to the "natural" word size for the processor. -- Brian R. Bainter KA7TXA AT&T Technologies Atlanta Works {cbosgd, gatech, ihnp4, moss, mtune, ulysses}akgua!brb
gwyn@smoke.ARPA (Doug Gwyn ) (08/03/88)
A short is required to be at least 16 bits. It may be as big as a long. It must not be bigger than a long nor than an int, and must not be smaller than a char. (A char is not necessarily 8 bits.) There are undobtedly toy "C" implementations that don't follow the rules.
guy@gorodish.Sun.COM (Guy Harris) (08/03/88)
> No. I have seen at least one compiler where sizeof(short) is one > byte. In which case the vendor of the compiler either 1) won't make it ANSI C-conformant or 2) will make "sizeof (short)" two bytes (assuming 8-bit bytes here; if bytes are 16 bits they're safe). The January 11, 1988 ANSI C draft indicates that a "short int" must be able to hold values in the range -32767 to 32767; it may be able to hold values outside that range, but it must be able to hold values inside that range.
henry@utzoo.uucp (Henry Spencer) (08/03/88)
In article <214@ISIDAPS5.UUCP> mike@ISIDAPS5.UUCP (Mike Maloney) writes: >Is the size of a (signed or unsigned) short integer guarenteed to >be two bytes? No. >I need to manipulate and compare some unsigned ints >modulo 65536. It would be clean and convenient to just let the >machine handle my wrap-around from 0 to 0xffff and verse-vica. For unsigned numbers this would work, *if* you can find an unsigned size that is two bytes long. There are no guarantees at all about that. (For example, I believe there's a C compiler for the pdp10, and shorts would pretty well have to be either 18 or 36 bits there. What they are on a 64-bit machine like a Cray, I have no idea, but I wouldn't count on them being 16.) I think the most portable way is to use (perhaps unsigned) long and do an "&0xffff" at strategic places. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
peter@ficc.UUCP (Peter da Silva) (08/03/88)
Not trying to start a war or anything, but how far do you really have to stretch the language to allow: int a:16; outside of a struct? This would let you solve all the "how big is a short" type problems with ease. -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
mike@ntmtka.Ntmtka.MN.ORG (Mike Tietel) (08/04/88)
In article <214@ISIDAPS5.UUCP>, mike@ISIDAPS5.UUCP (Mike Maloney) writes: > Is the size of a (signed or unsigned) short integer guarenteed to > be two bytes? ... No. All that can be guarenteed is that: (sizeof short) <= (sizeof int) <= (sizeof long) Therefore, there are no guarentees about the absolute size of a short. Even under two different compiler implementations for the same hardware, the sizes might be different. mike tietel -- mike@ntmtka.mn.org UUCP: ...!amdahl!bungia!ntmtka!mike
msb@sq.uucp (Mark Brader) (08/04/88)
> Shorts are at least two bytes, but may be longer, and bytes are at > least eight bits but may be more ... No, shorts are at least 16 bits, and bytes are at least 8 bits; that's all. (As per the draft standard; there has existed at least one implementation that did not obey this.) Mark Brader, utzoo!sq!msb, msb@sq.com C unions never strike!
peter@ficc.UUCP (Peter da Silva) (08/04/88)
In article <8300@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > A short is required to be at least 16 bits... > There are undobtedly toy "C" implementations that don't follow > the rules. When one is trying to fit ones software into a microcontroller with limited stack space, a compiler that expands a char to 16 bits on a function call can equally well be considered a toy. In this environment, of course, you aren't likely to be worried about porting "news" to the machine, so of course ANSIness is relatively unimportant. Still and all, categorizing compilers generating code for tight environments as "toys" isn't very nice. Sigh... shoulda stuck with FORTH. -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
ewing@se-sd.sandiego.ncr.com (David Ewing) (08/05/88)
In article <214@ISIDAPS5.UUCP> mike@ISIDAPS5.UUCP (Mike Maloney) writes: >Dear C-Heavies, > >Is the size of a (signed or unsigned) short integer guarenteed to >be two bytes? No, the only guarantees are short is less than OR EQUAL TO int which is less than OR EQUAL to long. For example, on the 32-bit machine where I work: long = 32 bits (signed or unsigned). int = 32 bits ( " ). short = 16 bits ( " ). David A. Ewing NCR -- Systems Engineering, San Diego
dg@lakart.UUCP (David Goodenough) (08/08/88)
From article <62505@sun.uucp>, by guy@gorodish.Sun.COM (Guy Harris): > someone else says: >> No. I have seen at least one compiler where sizeof(short) is one >> byte. > > In which case the vendor of the compiler either 1) won't make it ANSI > C-conformant or 2) will make "sizeof (short)" two bytes (assuming 8-bit bytes > here; if bytes are 16 bits they're safe). The following explanation springs to mind. There are old compilers still in use (saints help me - I use Leor Zolman's BDS C on my CP/M machine at home :-) that's vintage 1979!!). Now, back when the Gospel according to Kernighan and Ritchie came out, it said: sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) i.e. the above compiler conformed to K&R. However there are K&R conformant things that don't cut it with ANSI. Nobody's fault, just a fact of life. -- dg@lakart.UUCP - David Goodenough +---+ | +-+-+ ....... !harvard!cca!lakart!dg +-+-+ | +---+
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/10/88)
In article <1199@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: | Not trying to start a war or anything, but how far do you really have | to stretch the language to allow: | | int a:16; I proposed something like this to X3J11 in the first year or so (I was only there two years). What I suggested was size in bytes, allowing: int foo*4 -or- int*4 foo; The feeling was that it was (a) not really needed and (b) too much like fortran. I like your idea better, but the few cases where you want exact size rather than minimum size probably don't justify inclusion. It would be nice some times to be able to specify a bit array in a struct, as in: struct bit_array { unsigned states:3[40]; }; I think that's a more likely addition, since it adds very little code to the compiler and can't be any less efficient than does it yourself in a series of unreadable shifts and ANDs. I would really like to see a "packed struct," also. This would be a struct packed on byte boundaries without fill, no matter *how bad* the code was to use them. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
thad@cup.portal.com (08/16/88)
Interesting this subject is coming up! I implemented the following in one C
compiler to assure compatibility with existing assembler structures, and it
has been a lifesaver:
bit[:n] name;
which defaults to a one-bit-wide
Some examples:
bit DiskBitmap[_SECTORS];
bit:2 foo;
Makes for extrememly readable AND maintainable code.
There are situations where storage compaction is of far greater importance
than the access time (e.g. in one of my DBMS products).
Constructs such as the following do NOT function "properly" with most compilers:
struct OneBitElement {
int foo : 1;
};
struct MyDataBlock {
int bar;
struct OneBitElement bletch[32];
};
I cannot believe I'm the only one with this requirement. Sheesh.danw@tekchips.CRL.TEK.COM (Daniel E. Wilson;1432;58-790;;) (08/21/88)
> I proposed something like this to X3J11 in the first year or so (I was > only there two years). What I suggested was size in bytes, allowing: > int foo*4 > -or- > int*4 foo; > The feeling was that it was (a) not really needed and (b) too much like > fortran. I like your idea better, but the few cases where you want exact > size rather than minimum size probably don't justify inclusion. I thought this was C not FORTRAN 77. The reason why the size of an int is not tightly defined is so that the compiler will use the best size for the computer. Usually so the program will wind up being faster. > I would really like to see a "packed struct," also. It would seem that a well written compiler would already choose the best alignments of members in a structure. Also remember that some types of hardware can't address a word on a byte boundry (PDP-11) and so this option would end up not being implemented. A good 80x86 compiler would probably not pad a structure because the hardware doesn't care how an int is aligned.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/23/88)
In article <2970@tekcrl.CRL.TEK.COM> danw@tekchips.CRL.TEK.COM (Daniel E. Wilson;1432;58-790;;) writes: | > I proposed something like this to X3J11 in the first year or so (I was | > only there two years). What I suggested was size in bytes, allowing: | > int foo*4 | > -or- | > int*4 foo; | > The feeling was that it was (a) not really needed and (b) too much like | > fortran. I like your idea better, but the few cases where you want exact | > size rather than minimum size probably don't justify inclusion. | | I thought this was C not FORTRAN 77. The reason why the size of an | int is not tightly defined is so that the compiler will use the | best size for the computer. Usually so the program will wind up being | faster. I think I should have quoted a bit of the previous posting. The intent was to give the compiler all the information so it could choose the best representation. Currently to get a four byte (or more) integer I say long. dpANS says that this will be at least 32 bits. If I need four bytes and short is 2, int is 4, and long is 8, I could say int*4 and get the best data type which would hold the data. There was no intension of forcing high overhead on any implemention, just giving the compiler more information, like the register declaration. Consider some programs which need at least 48 bit integers. Currently that information has to be carried in the documentation, so you know it runs on a Cray, CDC, mini-super, etc. If I could say int*6 the compiler on a smaller machine now has the option of generating an error "not on this machine, you don't", or generating code which gives me the precision I need, and hopefully a warning that it is being done in software. I hate to say it, but 'noalias' didn't offent me a bit. It was a way to let compilers generate better code, and I didn't have to learn or use it if I chose not to. I believe in telling the compiler as much as I can, because guesses are usually not optimal. | > I would really like to see a "packed struct," also. | | It would seem that a well written compiler would already choose the | best alignments of members in a structure. Also remember that some | types of hardware can't address a word on a byte boundry (PDP-11) and | so this option would end up not being implemented. A good 80x86 compiler | would probably not pad a structure because the hardware doesn't care how | an int is aligned. The problem here is that you and I may disagree about "best alignment". If I need best speed then the compiler probably does that. If I need to get the absolute smallest packing of data, then I can use the 'packed struct' concept. Good compilers for the 80x86 do pack structures, because it makes things run faster. The 80286 takes one (or two) additional clocks to fetch unaligned, as does the 80386 if not aligned mod four. I believe the same is true on the 68k series, but my hardware manual isn't handy. It's a tradeoff between space and speed. The Microsoft C compilers allow the user to comtrol the packing. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
bill@proxftl.UUCP (T. William Wells) (08/26/88)
In article <11941@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
: Consider some programs which need at least 48 bit integers. Currently
: that information has to be carried in the documentation, so you know it
: runs on a Cray, CDC, mini-super, etc. If I could say int*6 the compiler
: on a smaller machine now has the option of generating an error "not on
: this machine, you don't", or generating code which gives me the
: precision I need, and hopefully a warning that it is being done in
: software.
That might be a good idea: allow an [unsigned] int*size (which
should be in bits since the standard defines things in terms of
bits) which, if the size is greater than 32 bits, is ...? The
`...' is there because the current standard does not define a
class of behavior which permits the compiler to fail to translate
a correct program construct.
The best way to get this is for some compiler writers to put it
into their compiler. If the extension proves popular, when it
comes time to revise the standard, it no doubt will get added to
the standard.
: Good compilers for the 80x86 do pack structures, because it makes
^pad?
: things run faster. The 80286 takes one (or two) additional clocks to
: fetch unaligned, as does the 80386 if not aligned mod four. I believe
: the same is true on the 68k series, but my hardware manual isn't handy.
: It's a tradeoff between space and speed.
The 68000 actually has real alignment restrictions. Odd accesses
for integers can cause a fault. I think later processors in the
series relax the restriction but are still slower for some
unaligned accesses.
---
Bill
novavax!proxftl!billpeter@ficc.uu.net (Peter da Silva) (08/29/88)
In article <625@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes: > In article <11941@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes about 'int*6' as a portable declaration for a 6 byte integer. > That might be a good idea: allow an [unsigned] int*size (which > should be in bits since the standard defines things in terms of > bits) which, if the size is greater than 32 bits, is ...? The Make it 'int:size' to provide textual consitency with bit-feilds. Also, it shuld be signed. If you want an unsigned, make it 'unsigned int:size'. > The best way to get this is for some compiler writers to put it > into their compiler. I put something like it into Small-C once, but nobody but me ever saw it. I wanna say 'int:9 color' or 'int color:9' and only use up one byte on a Honeywell or Sperry. -- Peter da Silva `-_-' Ferranti International Controls Corporation. "Have you hugged U your wolf today?" peter@ficc.uu.net
bill@proxftl.UUCP (T. William Wells) (08/30/88)
In article <1382@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: : In article <625@proxftl.UUCP>, bill@proxftl.UUCP (T. William Wells) writes: : > In article <11941@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) : writes about 'int*6' as a portable declaration for a 6 byte integer. : : > That might be a good idea: allow an [unsigned] int*size (which : > should be in bits since the standard defines things in terms of : > bits) which, if the size is greater than 32 bits, is ...? The : : Make it 'int:size' to provide textual consitency with bit-feilds. Also, : it shuld be signed. If you want an unsigned, make it 'unsigned int:size'. I thought about using colon but decided against it. Tell me, would: int:16; be a bit field declaration or a field declaration with no members? Obviously the former, but the possibility of confusion is not desirable. It might make the language non-LALR as well. Also, my use of [unsigned] was intended as part of the syntax, to imply that unsigned could be used for the declaration. Sorry for the ambiguity. : > The best way to get this is for some compiler writers to put it : > into their compiler. : : I put something like it into Small-C once, but nobody but me ever saw it. Better would be into something like the Gnu C compiler. Whatever Stallman's political idiocies, the compiler does seem rather well known. The Small-C compiler has the drawback that it isn't a complete implementation of C, that makes it kinda invisible to those of us who have to do real work in C. :-) : I wanna say 'int:9 color' or 'int color:9' and only use up one byte : on a Honeywell or Sperry. Would be nice. Here is an extension to this idea: use short*n to indicate that you want it packed if this is reasonable, and int*n to indicate that you don't care if it is packed. --- Bill novavax!proxftl!bill
gwyn@smoke.ARPA (Doug Gwyn ) (08/31/88)
In article <1382@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I wanna say 'int:9 color' or 'int color:9' and only use up one byte >on a Honeywell or Sperry. Yes! It annoys me that people have been brainwashed into thinking that a "byte" is necessarily 8 bits and that there is something special about that chunk size other than its current popularity. CDCs, older ones at least, had generic "byte" instructions that could handle any reasonable number of contiguous bits as a unit. It is the BIT that is truly fundamental; if one wishes to propose some data size improvements to a C-like language, please improve our access to bits and arbitrary clusters of them.
mouse@mcgill-vision.UUCP (der Mouse) (09/02/88)
In article <8398@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > In article <1382@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> I wanna say 'int:9 color' or 'int color:9' and only use up one byte >> on a Honeywell or Sperry. > Yes! It annoys me that people have been brainwashed into thinking > that a "byte" is necessarily 8 bits and that there is something > special about that chunk size other than its current popularity. Well, lots of things work out nicelier (:-) when the chunk sizes are powers of two. I wouldn't mind 16-bit "byte"s, but I sure wouldn't be fond of 9-bit "byte"s. > It is the BIT that is truly fundamental; Tell that to someone with a decimal-based calculator. (Yes, I know the dpANS requires unsigned integers to behave "as if" binary were the basic numbering system.) By the way, does anyone know of a non-mechanical digital calculator or computer that isn't essentially binary? der Mouse
karl@haddock.ima.isc.com (Karl Heuer) (09/03/88)
People have suggested that some notation like `int:9 foo' should exist, which declaration would reserve two bytes on a Vax, but only one on a Honeywell. I will again point out that it is already possible to do this within the current language, via a header file "ints.h". On a PDP-11, it would contain: typedef char int_1, int_2, int_3, int_4, int_5, int_6, int_7, int_8; typedef short int_9, int_10, /*...*/, int_16; typedef long int_17, /*...*/, int_32; typedef unsigned char uint_1, /*...*/, uint_8; typedef unsigned short uint_9, /*...*/, uint_16; typedef unsigned long uint_17, /*...*/, uint_32; Using the constants in ANSI C's <limits.h>, one could even write a universal implementation of "ints.h" which is portable to all machines (given an upper limit on the number of bits being supported). (One admitted flaw: the bitwidth must be specified directly in this scheme; you can't compute it at compile-time.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
chip@ateng.uucp (Chip Salzenberg) (09/06/88)
According to karl@haddock.ima.isc.com (Karl Heuer): > typedef short int_9, int_10, /*...*/, int_16; > typedef long int_17, /*...*/, int_32; [etc.] >(One admitted flaw: the bitwidth must be specified directly in this scheme; >you can't compute it at compile-time.) Perhaps you can: #define xintbits(n) int_ ## n #define intbits(n) xintbits(n) /* The nested macro expands the argument before concatenating tokens. */ #define COLORBITS 9 typedef intbits(COLORBITS) color_t; -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. The urgent leaves no time for the important.
karl@haddock.ima.isc.com (Karl Heuer) (09/08/88)
chip@ateng.uucp (Chip Salzenberg) writes: >According to karl@haddock.ima.isc.com (Karl Heuer): >>(One admitted flaw: the bitwidth must be specified directly in this scheme; >>you can't compute it at compile-time.) > >Perhaps you can [using token pasting] I thought of that, but it's not particularly useful, since it won't handle `#define COLORBITS (4+5)'. It could be done with m4, but cpp has no option to preevaluate the RHS. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint