The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Bytes, words, ints...

I have a spec for a data struct and it says, say, 2 bytes for
something (0-65535)

I want to use an unsigned int, but I have issues with that because
won't the definition of int change once 64 bit machines become the
defacto standard?

I know this is probably a long time coming and it shouldn't affect me
for a while but what're your opinions?
Justin Bouffard Send private email
Wednesday, September 21, 2005
 
 
Depends on platform.  Most Unix/Linux (incl. Solaris) define a programming paradigm called "ILP32/ILP64" where:

int == 32 bits
long == 32 or 64 bits, depending on platform
long long == 64 bits
pointer == 32 or 64 bits, depending on platform

http://docs.sun.com/app/docs/doc/806-0477
http://gcc.fyxm.net/summit/2003/Porting%20to%2064%20bit.pdf



Windows, unfortunately, has its own standard called "LLP64" where

int == 32 bits
long == 32 bits
long long == 64 bits
pointer == 32 or 64 bits, depending on platform

http://msdn.microsoft.com/library/en-us/dnnetserv/html/ws03-64-bitwindevover.asp?frame=true#ws03-64-bitwindevover_topic3
http://www.devx.com/amd/Article/27474
BillT Send private email
Wednesday, September 21, 2005
 
 
"The spec says one thing but I really want to do something else, whaaa, why are specs always so bad?!"

Maybe you could, oh, hell, I don't know, possibly actually do your job properly?  If you really have a good argument why the spec is wrong, why not consider possibly talking to be person who write it?  No?

Heh, I love that "64-bit is probably still a long time coming" thing to.  I guess it's still a few more years til you upgrade to one of those newfangled 16 bit computers as well, no?  64-bit is here now, and you get to deal with it now.

My opinion is that you need to buy a basic "introduction to coding" book, and actually learn what the hell you're talking about. If you don't understand basic data types like "integer" then you're simply not competent to work on a real application.

Btw, if you're offended, too damn bad - this is basic learning to program stuff, not complex problems that professionals need help with.

If you said you were in school needing help with homework, that would be fine, we all need to learn the basics somehow. But if you're really working as a computer programmer, then you either know this stuff, or need to go back to school.

Wednesday, September 21, 2005
 
 
"I want to use an unsigned int, but I have issues with that because won't the definition of int change once 64 bit machines become the defacto standard?"

Yes, and... What's the problem? Why would a change affect you? An int is already larger than 2 bytes for 32-bit environments, so why does it matter if it goes to 64 bits?
sloop
Wednesday, September 21, 2005
 
 
Agree with sloop. When you want an int, and nothing else, and you really don't care about bit width, use 'int'.

So it becomes 64 bit on some platform. That platform was designed to deal with ints optimally at 64 bits. Use it.
hoser Send private email
Wednesday, September 21, 2005
 
 
Umm... The standard says nothing about the size - it only specifies the MINIMUM size of an int, as some multiple of the size of a char.

ie, suppose an int on my platform was 4, and chars were 8 bits - that would make an int 4*8=32bits

However, if a char was 16 bits - an int would become 64bits.

If you are required to use exact specific sizes, you're recommended to use something compiler-specific such as uint32_t
Arafangion Send private email
Wednesday, September 21, 2005
 
 
>  as some multiple of the size of a char

Um, no; sorry. Please go read the C/C++ standard.
Ian Boys Send private email
Wednesday, September 21, 2005
 
 
The C89 Standard?  I confess, most of my working knowledge of this area comes from IRC, which tends to be a little pedantic.
Arafangion Send private email
Wednesday, September 21, 2005
 
 
The reason I say "some multiple of a size of char" is becuase afaik, sizeof(char) == 1 by definiton.  It could be 16, and I've been told that some old microcontrollers had 6 bits.
Arafangion Send private email
Wednesday, September 21, 2005
 
 
Since 'C' is used for low-level programming, you'd think that there would be easy and simple ways to 'fix' the size of the types.

And in fact most types are fixed in size -- it's only this magic 'int' that changes from implementation to implementation.  Which is fine, until you positively, absolutely must have fixed sizes.

You could #define (or typedef) a u_int16 type as an unsigned short -- I believe shorts are fixed at 16 bits.

Personally, I create a 'globals.h' header file to create my own, personally controlled data types, which have NO ambiguity about them.  Then I can tweak this file when/if I port to different platforms, to get around their default type sizes.
AllanL5
Wednesday, September 21, 2005
 
 
"Um, no; sorry. Please go read the C/C++ standard."

I'm not sure why you're disagreeing with this. See section 4.6 of TCPPPL:

"Sizes of C++ objects are expressed in terms of multiples of the size of a char" ...

"1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)" ...

"In addition, it is guaranteed that a char has at least 8 bits, a short at least 16 bits, and a long at least 32 bits."
sloop
Wednesday, September 21, 2005
 
 
Sloop, it does not follow that the standard specifies minimum sizes of types in terms of multiples of char. In the embedded world there are conforming implementations on which sizeof(char) == sizeof(int) == sizeof(long) == 1.
comp.lang.c refugee
Wednesday, September 21, 2005
 
 
Typo above, I should have said "standards" rather than "standard".

However, I believe the C and C++ standards of various vintages are broadly consistent in that they set the minimum sizes of integer data types in terms of bits rather than characters.

A short or an int have at least 16 bits and a long has at least 32 bits; a long is always at least as big as an int which is always at least as big as a short.

Newer standards are introducing a long long datatype which is guaranteed to have at least 64 bits.
Ian Boys Send private email
Wednesday, September 21, 2005
 
 
"Sloop, it does not follow that the standard specifies minimum sizes of types in terms of multiples of char. In the embedded world there are conforming implementations on which sizeof(char) == sizeof(int) == sizeof(long) == 1."

You're right. The size of other types are not defined in terms of a _fixed_ multiple of char, even though they are always some multiple of char.
sloop
Thursday, September 22, 2005
 
 
Using 'int' and so on is about making basic (and possibly flawed) assumptions about their size and deciding that it really doesn't matter much.  This works in 99% of occasions.  They are abstractions.  Abstractions are leaky.

When you start having to interoperate at a binary level with other programs (or your same program, but compiled with a different compiler or on another platform) then you have to start worrying about the range, size, alignment, endianness and packing of variables and data structures.

The first step is stdint.h and ctypes.h etc.  The OT particular example would be to use the uint16_t.  0.7% of cases, this is a step far enough.

Which leaves us with 0.3% of cases where you need to consider packing, alignment, endianness and so on.  This is when you start to realise that it is best done with a library.  wxWidgets, for example, has streams that automatically manage translation when reading or writing, so allowing you to manipulate data internally in the optimal endian.

Doubtless 0.05% of cases the data format is beyond a library like wxWidgets, or is so performance critical or otherwise, that you end up making your own library.

Once you have your own library, doubtless you start imagining it can be used by the 0.3% above.  But 0.05% of those will still fall through to requiring dedicated code.  Such is life.
new nick, new rep
Thursday, September 22, 2005
 
 
Don't work with the representation; work with the values.

Wrong:

/* Requires native unsigned 16 bit type to wrap around on 65535 */
unsigned short int i;
i = a + b + c;
unsigned char *p = (unsigned char *)&i;
lobyte = p[0];
hibyte = p[1];

Right:

i = (a + b + c) & 65535;
lobyte = i & 255;
hibyte = (i >> 8) & 255;

The latter doesn't make any assumptions about the number of bits, endianness or padding. You can use any unsigned integer type for i with at least 16 bits.
Secure
Thursday, September 22, 2005
 
 
Option #1:

#include <stdint.h>

uint16_t my_value;

Behold, a two-byte value, even on a 64-bit platform.  You need a C99 compiler for this.

Option #2:

If your compiler doesn't offer stdint.h...

Define your own types like uint16, uint32, etc.  Use some pre-processor logic to typdef these to the apropriate variable type (short, int, long, long long, etc).
Myron A. Semack Send private email
Monday, September 26, 2005
 
 
What the OP says is that the spec he has asks for 2 bytes for whatever-it-is.

Is it an int? is it a bitfield? 2 ASCII characters? what actually does it represent?

If it really is an int, CAN it logically have a negative value?

Does the spec say "exactly 2 bytes" (if so, why) or does it say "at least 2 bytes".

These are all questions that you should ask before laying into the OP or each other.
revert my buffer
Tuesday, October 04, 2005
 
 
The OP says the spec is for an unsigned 16 bit integer. You are a bit late to be proving yourself unable to read and comprehend plain English.
Ian Boys Send private email
Tuesday, October 04, 2005
 
 
" I have a spec for a data struct and it says, say, 2 bytes for something (0-65535)"

Where does it say it's an int? It's implied in the next para, but is it spec'd like that?
revert my buffer
Wednesday, October 05, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz