By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,137 Members | 1,024 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,137 IT Pros & Developers. It's quick & easy.

64 bit porting - size_t vs unsigned int

P: n/a
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.

Dec 23 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
<me****@gmail.comwrote in message
news:11********************@i12g2000cwa.googlegrou ps.com...
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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

Dec 23 '06 #2

P: n/a
Stephen Sprunk wrote:
<me****@gmail.comwrote in message
news:11********************@i12g2000cwa.googlegrou ps.com...
>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).
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.

Dec 23 '06 #3

P: n/a
Martin Ambuhl wrote:
Stephen Sprunk wrote:
<me****@gmail.comwrote in message
news:11********************@i12g2000cwa.googlegrou ps.com...
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).

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.

Dec 23 '06 #4

P: n/a
On 22 Dec 2006 21:49:33 -0800, me****@gmail.com wrote:
>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
Dec 23 '06 #5

P: n/a
<me****@gmail.comwrote in message
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.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Dec 23 '06 #6

P: n/a
me****@gmail.com wrote:
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.

Dec 23 '06 #7

P: n/a
"Martin Ambuhl" <ma*****@earthlink.netwrote in message
news:4v*************@mid.individual.net...
Stephen Sprunk wrote:
><me****@gmail.comwrote in message
news:11********************@i12g2000cwa.googlegro ups.com...
>>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).

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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

Dec 23 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.