64 bit porting - size_t vs unsigned int

[meshko]

I'm just curious what people do with the code like this:
size_t len = strlen(sz_message);
write(fd, sz_message, len);

on Windows where in write() the third argument to write is unsigned int
now that size_t is 64 bit and unsigned int is, well, still 32 bit?

I apologize that this is a Windows specific question, I didn't realize
until I was half way through writing this that on other systems send,
write etc are all declared to take size_t.

 

[Stephen Sprunk]

I'm just curious what people do with the code like this:
size_t len = strlen(sz_message);
write(fd, sz_message, len);

on Windows where in write() the third argument to write is unsigned
int
now that size_t is 64 bit and unsigned int is, well, still 32 bit?

The compiler will convert len to unsigned when passing it to the
function (though a cast will help make it more obvious, and possibly
silence compiler warnings). That does leave a potential bug when len is
greater than UINT_MAX, but if your ints are 32-bit and sz_message is a
string as the name and context implies, what are the odds of that _ever_
happening? And how horribly will your app fail if it does? Your
program will probably freeze up anyways trying to strlen() a >4GB object


In theory, you should test to see if (len > UINT_MAX) and if so loop
until the entire message is written. If you _know_ that len will never
exceed UINT_MAX, though, you can leave it out. However, be very careful
when assuming you "know" things like that; lots of stuff broke when
files >4GB started appearing.

I apologize that this is a Windows specific question, I didn't realize
until I was half way through writing this that on other systems send,
write etc are all declared to take size_t.

If you had provided the prototype for write(), we could answer without
knowing the platform was Windows

S

 

[Martin Ambuhl]

The compiler will convert len to unsigned when passing it to the
function (though a cast will help make it more obvious, and possibly
silence compiler warnings).

len is declared as a size_t, so is by definition unsigned. There is no
conversion to unsigned. Adding a cast will just add confusion. The
problem is that one the OP's system a size_t is wider than an unsigned
int. Obviously, if he never uses a value larger than UINT_MAX for len,
then there is no problem.

 

[Stephen Sprunk]

len is declared as a size_t, so is by definition unsigned. There is
no conversion to unsigned.

I meant conversion to unsigned int; I typically leave "int" out since
it's unneeded. Perhaps "truncation" would have been clearer.

Adding a cast will just add confusion.

Not if the compiler is smart enough to warn you when you try to pass
something larger than an unsigned int to something prototyped to take an
unsigned int. If so, a cast will silence that warning. Doing so might
be good or bad, depending on context; warnings are there for a reason.

The problem is that one the OP's system a size_t is wider than an
unsigned int. Obviously, if he never uses a value larger than
UINT_MAX
for len, then there is no problem.

.... which I pointed out in the remainder of my response, with caveats.

S

 

[Guest]

len is declared as a size_t, so is by definition unsigned.

size_t is an unsigned integer type. It could be unsigned (or
equivalently, unsigned int), unsigned long, unsigned long long,
uint32_t, or any other unsigned integer type.

 

[Barry Schwarz]

I'm just curious what people do with the code like this:
size_t len = strlen(sz_message);
write(fd, sz_message, len);

on Windows where in write() the third argument to write is unsigned int
now that size_t is 64 bit and unsigned int is, well, still 32 bit?

If there is a prototype in scope for write, the compiler will
generated code to convert the argument from its actual type to the
type expected by the function. If the value fits, everything is OK.
If the value does not fit, the behavior is undefined.

Some compilers generate a diagnostic indicating that converting from a
"larger" type to a "smaller" one can cause problems.


Remove del for email

 

[Malcolm]

I'm just curious what people do with the code like this:
size_t len = strlen(sz_message);
write(fd, sz_message, len);

on Windows where in write() the third argument to write is unsigned int
now that size_t is 64 bit and unsigned int is, well, still 32 bit?

I apologize that this is a Windows specific question, I didn't realize
until I was half way through writing this that on other systems send,
write etc are all declared to take size_t.

That's what ahppens when you've got lots of integer types swilling about.
Join my campaign for 64 bit ints.

 

[christian.bau]

I'm just curious what people do with the code like this:
size_t len = strlen(sz_message);
write(fd, sz_message, len);

on Windows where in write() the third argument to write is unsigned int
now that size_t is 64 bit and unsigned int is, well, still 32 bit?

I apologize that this is a Windows specific question, I didn't realize
until I was half way through writing this that on other systems send,
write etc are all declared to take size_t.

Even if size_t is 64 bit on one system and 32 bit on another system,
and the argument for write () is only 32 bit, that won't cause you any
problems as long as the string sz_message is the same. Whether or not
you can write the contents of sz_message doesn't depend on the number
of bits in size_t.