10

The question is actually somewhat broader.

Based on the last 15 years experience I currently assume that size of types is as follows:

byte = 8 bit

short = 2 bytes

int = 4 bytes

long long = 8 bytes

Is there a modern OS where this assumption can be challenged?

Vladislav Vaintroub
  • 5,308
  • 25
  • 31
  • 6
    It's not so much about the OS or compiler, it's about the underlying hardware. – Oliver Charlesworth Dec 03 '11 at 00:22
  • 8
    If you count embedded systems there are several (PIC, AVR, etc). – Owen Dec 03 '11 at 00:25
  • 7
    All kinds of embedded systems. – Brian Neal Dec 03 '11 at 00:26
  • 9
    According to [Wikipedia](http://en.wikipedia.org/wiki/64-bit#64-bit_data_models), Solaris for SPARC64 and Unicos both use 8-byte `int`. In fact, on Unicos, short is also 8 bytes! – Raymond Chen Dec 03 '11 at 00:30
  • 2
    Some compilers support the ILP64 model: meaning that ints, longs and pointers are 64 bits. – Ferruccio Dec 03 '11 at 00:37
  • This question is similar: http://stackoverflow.com/questions/589575/size-of-int-long-etc – Michas Dec 03 '11 at 00:56
  • Yes, looks similar, though I would not ask about sizeof(long) ;) – Vladislav Vaintroub Dec 03 '11 at 01:13
  • 2
    @OliCharlesworth it is absolutely about compiler. Size of pointer depends on the architecture, size of int doesn't. – MK. Dec 03 '11 at 01:24
  • @RaymondChen: Unicos on the T90 has 64-bit `short`; Unicos on the T3E (Alpha processor) has 32-bit `short`. – Keith Thompson Dec 03 '11 at 01:31
  • @MK: Whilst size of integer is up to the compiler, it's overwhelmingly chosen to match the native word size of the ALU, etc. A similar argument holds for pointers. – Oliver Charlesworth Dec 03 '11 at 01:40
  • 2
    Making `int` 64 bits and `char` 8 bits means that you can't have predefined types for both 16 and 32 bits; `short` can be one or the other, but not both. C99 introduced extended integer types, but I don't know of any compilers that actually provide them. That's probably why 64-bit `int` is still uncommon even on 64-bit systems. – Keith Thompson Dec 03 '11 at 01:42
  • @KeithThompson: you mean `stdint.h`? What about glibc? – ninjalj Dec 03 '11 at 14:47
  • @ninjalj: No, C99 introduced the concept of *extended integer types*, whose names ight be compiler-defined keywords like `__uint128`. The typedefs in `` might be defined either as normal types like `long long`, or as extended types. I don't know what glibc would have to do with it. – Keith Thompson Dec 03 '11 at 18:42
  • `long long` is usually *16-bytes* on 64-bit unices along with 8-byte `long`, while 32-bit unices and both 32 and 64-bit windows have 4-byte `long` and 8-byte `long long`. The assumption about `long long` is not widely applicable. – Jan Hudec Sep 11 '12 at 09:40
  • @KeithThompson: The `__int??` and `__uint??` types were taken from Microsoft compiler, which had them for ages (though IIRC it still does not have all of C99, because Microsoft only focuses on C++). Gcc does not, because the standard types always covered all that was needed so far (well, when it didn't, gcc invented the `long long`). – Jan Hudec Sep 11 '12 at 09:42
  • 1
    @Jan Hudec - I claim tat there is no Unix with 16 byte or 128 bit "long long". Prove me wrong and tell where you have seen it;) – Vladislav Vaintroub Sep 11 '12 at 16:43
  • @VladislavVaintroub: Hm, you are right. I've seen somewhere that it should generally be 128-bit, but it isn't. – Jan Hudec Sep 12 '12 at 07:51
  • @Jan Hudec, perhaps, what you've seen was about "long double". http://en.wikipedia.org/wiki/Long_double mentions 128-bit couple of times. – Vladislav Vaintroub Sep 12 '12 at 10:54

5 Answers5

4

Whether or not such "modern" systems exist, you should static_assert assert those assumptions in your code so that if your code is ever ported to a platform where the assumption is incorrect, the person doing the porting will be alerted to the problem immediately.

Raymond Chen
  • 44,448
  • 11
  • 96
  • 135
3

The standard is intentionally vague on this subject, only specifying:

  • C90: sizeof(short) <= sizeof(int) <= sizeof(long)

  • C99: sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long)

Furthermore, C99 only requires that int be at least a 16-bit value.

Also, 'byte' is not a C datatype.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
Joe
  • 41,484
  • 20
  • 104
  • 125
  • 3
    Shouldn't be `<= sizeof(long) <= sizeof(long long)`? – Michas Dec 03 '11 at 00:51
  • 3
    I know standard is vague, my question was more from practical point of view. – Vladislav Vaintroub Dec 03 '11 at 00:55
  • 1
    @VladislavVaintroub: If you want a practical answer I would use the types defined in the `stdint.h` header. – Blastfurnace Dec 03 '11 at 01:34
  • 3
    @Michas: Yes, it's definitely `<=` (I've edited the answer accordingly). But the relationships are actually stated in terms of *ranges*, not sizes (the requirement for binary representations implies minimum sizes, but not all bits necessarily contribute to the value). The range of each type in the following list is a subset of the range of the following type: `signed char`, `short`, `int`, `long`, `long long` (the latter was introduced in C99). The minimum sizes in bits are: `char`: 8, `short`: 16, `int`: 16, `long`: 32, `long long` 64 (again, actually defined in terms of ranges). – Keith Thompson Dec 03 '11 at 01:37
  • 2
    It's true that `byte` is not a C datatype, but the C standard does use the word to refer to an "addressable unit of data storage large enough to hold any member of the basic character set of the execution environment". Other than on some embedded systems, a C byte is almost always 8 bits (it must always be at least 8 bits). `unsigned char` is effectively a byte type (`char`, `signed char`, and `unsigned char` are all one byte in size, by definition.) – Keith Thompson Dec 03 '11 at 01:39
  • @Blastfurnace, you're expecting too modern environment:) I do also work with environments where stdint.h does not exist – Vladislav Vaintroub Dec 03 '11 at 02:43
  • -1 for a completely non-useful answer -- the question is specifically asking about what actual implementations do, not what the standard guarentees – Chris Dodd Dec 03 '11 at 07:14
  • @Chris: My point is: do not assume that majority rules here. Just because many environments treat the same type names the same in terms of size, it is dangerous to believe that is a de-facto rule. – Joe Dec 03 '11 at 12:41
  • @Joe, the question wasn't about the majority, the question was about exceptions to the majority. This answer contains some good background information, but it doesn't answer the question - at all. – Mark Ransom Dec 06 '11 at 23:08
0

According to this Unicos has int as 64bit. Of course the definition of a "modern" compiler is pretty vague. You can still buy Borland C++ for MS DOS and have your ints are 16bit, but is that modern?

MK.
  • 33,605
  • 18
  • 74
  • 111
  • 1
    Has anyone actually seen/worked with Unicos? Everybody points to the same Wikipedia article:) Is Unicos as rare as say, a unicorn? – Vladislav Vaintroub Dec 03 '11 at 02:41
  • @Vladislav - If your assumption has been true for the last 15 years, what about the next 15 years? I have been doing this for 30 years and moved from 8 bits to 64 bits in that time. – Bo Persson Dec 03 '11 at 04:43
  • @Bo, my theory is that further increase in bitness less likely to occur at the same pace, once 64 bit has been reached. But nevermind that I believe that next-gen 128 bit integer won't be char,short,int,long or long long. It will be int128_t or long long long or something like that.. – Vladislav Vaintroub Dec 03 '11 at 11:27
0

You have pretty much platforms (especially in embedded) where it is not. You e.g. can have 2-octet char.

Andrey Regentov
  • 3,687
  • 4
  • 34
  • 40
0

There is probably one exception.

long long = error

I've heard there are problems with old Microsoft C compilers. I've seen some workarounds in source code. However Microsoft 32-bit C/C++ Optimizing Compiler Version 16 (from Visual Studio 2010) do have long long.

Michas
  • 8,534
  • 6
  • 38
  • 62