Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > size_t problems

Reply
Thread Tools

size_t problems

 
 
jacob navia
Guest
Posts: n/a
 
      08-29-2007
Malcolm McLean wrote:
>
> "jacob navia" <(E-Mail Removed)> wrote in message
> news:46d5c46d$0$5108$(E-Mail Removed)...
>> I am trying to compile as much code in 64 bit mode as
>> possible to test the 64 bit version of lcc-win.
>>
>> The problem appears now that size_t is now 64 bits.
>>
>> Fine. It has to be since there are objects that are more than 4GB
>> long.
>>
>> The problem is, when you have in thousands of places
>>
>> int s;
>>
>> // ...
>> s = strlen(str) ;
>>
>> Since strlen returns a size_t, we have a 64 bit result being
>> assigned to a 32 bit int.
>>
>> This can be correct, and in 99.9999999999999999999999999%
>> of the cases the string will be smaller than 2GB...
>>
>> Now the problem:
>>
>> Since I warn each time a narrowing conversion is done (since
>> that could loose data) I end up with hundreds of warnings each time
>> a construct like int a = strlen(...) appears. This clutters
>> everything, and important warnings go lost.
>>
>>
>> I do not know how to get out of this problem. Maybe any of you has
>> a good idea? How do you solve this when porting to 64 bits?
>>

> There's a very obvious answer to that one. As a compiler-writer, youa re
> in a position to do it.
>


???

(Please excuse my stupidity by I do not see it...)

 
Reply With Quote
 
 
 
 
christian.bau
Guest
Posts: n/a
 
      08-29-2007
On Aug 29, 8:08 pm, jacob navia <(E-Mail Removed)> wrote:
> I am trying to compile as much code in 64 bit mode as
> possible to test the 64 bit version of lcc-win.
>
> The problem appears now that size_t is now 64 bits.
>
> Fine. It has to be since there are objects that are more than 4GB
> long.
>
> The problem is, when you have in thousands of places
>
> int s;
>
> // ...
> s = strlen(str) ;
>
> Since strlen returns a size_t, we have a 64 bit result being
> assigned to a 32 bit int.
>
> This can be correct, and in 99.9999999999999999999999999%
> of the cases the string will be smaller than 2GB...
>
> Now the problem:
>
> Since I warn each time a narrowing conversion is done (since
> that could loose data) I end up with hundreds of warnings each time
> a construct like int a = strlen(...) appears. This clutters
> everything, and important warnings go lost.
>
> I do not know how to get out of this problem. Maybe any of you has
> a good idea? How do you solve this when porting to 64 bits?


So the compiler is giving a warning when a 64 bit value is assigned to
a 32 bit variable, but not when a 32 bit unsigned value is assigned to
a 32 bit signed variable.

Well, just because you changed size_t to 64 bits doesn't make strings
any longer. strlen ("hello") still returns 5 and it will fit into an
int just as well as before. So you _could_, possibly as a compiler
option, mark certain functions as returning small(ish) values that
don't require a warning when stored in an int.

But maybe you should look at it from the point of view of a developer
who is switching from a 32 bit to a 64 bit compiler (or most likely
wants to write code that runs fine on a 32 bit and a 64 bit system),
and who _wants_ to fix problems. That programmer would _want_ the
warning and change the variable from int to something else.

Here is the approach that Apple takes: Define two typedefs, Int and
Uint (they actually use different names, but that doesn't matter).
These are used for almost all integer values. On a 32 bit system (32
bit int/long/size_t) they are equal to int/unsigned int, on a 64 bit
system (32 bit int, 64 bit long/size_t) they are equal to long/
unsigned long. Your warning problem goes away. Different types are
used on purpose so that if you mismatch int*/Int* or long*/Int* either
the 32 bit or 64 bit version will give you a compiler error.

Situations where you don't use these types: If you definitely need 64
bit, use long long. If you want to save space, use char/short/int as
suitable.

 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      08-29-2007

"jacob navia" <(E-Mail Removed)> wrote in message
news:46d5d579$0$27386$(E-Mail Removed)...
> Malcolm McLean wrote:
>> There's a very obvious answer to that one. As a compiler-writer, youa re
>> in a position to do it.
>>

>
> ???
>
> (Please excuse my stupidity by I do not see it...)
>

The campaign for 64 bit ints T-shirts obviously didn't generate enough
publicity. I still have a few left. XXL, one size fits all.

There are some good reasons for not making int 64 bits on a 64 bit machine,
which as a compiler-writer you will be well aware of. However typical
computers are going to have 64 bits of main address space for a very long
time to come, so it makes sense to get the language right now, and keep it
that way for the forseeable future, and not allow decisions to be dominated
by the need to maintain compatibility with legacy 32 bit libraries.


--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      08-29-2007
On Wed, 29 Aug 2007 20:52:20 +0100, Malcolm McLean wrote:

> "Ben Pfaff" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> I'd suggest fixing the code that does this to use size_t instead
>> of int. size_t is correct. int is, at best, an approximation to
>> correct. We've just had a pretty long thread with Malcolm McLean
>> discussing this very topic; perhaps you should refer to that
>> thread, if you're not already aware of it.
>>

> Yup. As I said, if people would use size_t consistently for every single
> calculation that ultimately ends up in an array index there wouldn't be such
> a problem. The reality is that people won't, and lots of code doesn't.


And lots of people do and lots of code does, and those people don't get
those problems on that code.

Which just goes to show, doing the right thing - using size_t - makes
perfect sense, and ignoring the right thing - as you persist in doing -
makes for problems.
 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      08-29-2007
On Aug 29, 12:08 pm, jacob navia <(E-Mail Removed)> wrote:
> I am trying to compile as much code in 64 bit mode as
> possible to test the 64 bit version of lcc-win.
>
> The problem appears now that size_t is now 64 bits.
>
> Fine. It has to be since there are objects that are more than 4GB
> long.
>
> The problem is, when you have in thousands of places
>
> int s;
>
> // ...
> s = strlen(str) ;
>
> Since strlen returns a size_t, we have a 64 bit result being
> assigned to a 32 bit int.
>
> This can be correct, and in 99.9999999999999999999999999%
> of the cases the string will be smaller than 2GB...
>
> Now the problem:
>
> Since I warn each time a narrowing conversion is done (since
> that could loose data) I end up with hundreds of warnings each time
> a construct like int a = strlen(...) appears. This clutters
> everything, and important warnings go lost.
>
> I do not know how to get out of this problem. Maybe any of you has
> a good idea? How do you solve this when porting to 64 bits?


Make your default int 64 bits, and be done with it.
Ought to be 64 bits on a 64 bit platform anyway.

 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      08-29-2007
On Aug 29, 12:51 pm, Keith Thompson <(E-Mail Removed)> wrote:
> "Malcolm McLean" <(E-Mail Removed)> writes:
> > "jacob navia" <(E-Mail Removed)> wrote in message
> >news:46d5c46d$0$5108$(E-Mail Removed)...

> [...]
> >>I am trying to compile as much code in 64 bit mode as
> >> possible to test the 64 bit version of lcc-win.

>
> >> The problem appears now that size_t is now 64 bits.

>
> [...]
>
>
>
>
>
> >> int s;

>
> >> // ...
> >> s = strlen(str) ;

>
> >> Since strlen returns a size_t, we have a 64 bit result being
> >> assigned to a 32 bit int.

>
> >> This can be correct, and in 99.9999999999999999999999999%
> >> of the cases the string will be smaller than 2GB...

>
> >> Now the problem:

>
> >> Since I warn each time a narrowing conversion is done (since
> >> that could loose data) I end up with hundreds of warnings each time
> >> a construct like int a = strlen(...) appears. This clutters
> >> everything, and important warnings go lost.

>
> >> I do not know how to get out of this problem. Maybe any of you has
> >> a good idea? How do you solve this when porting to 64 bits?

>
> > There's a very obvious answer to that one. As a compiler-writer, youa
> > re in a position to do it.

>
> I presume the solution you're suggesting is to make int 64 bits. How
> does this help? strlen() still returns size_t, and if int and size_t
> are both 64 bits, there will still be size_t values that cannot be
> stored in an int.


If strlen() returns a number bigger than 9,223,372,036,854,775,808
then there are bigger fish to fry.
Sure, Bill Gates supposedly said that nobody will ever need more than
640K of RAM, and so someday it may be true that strings longer than 9
quintillion bytes are common. But I guess it will be a minor problem
until he can get around to fully correcting the code the right way by
assigning size_t values to the return from strlen() and other things
that return a size_t.

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-29-2007
In article <46d5c46d$0$5108$(E-Mail Removed)>,
jacob navia <(E-Mail Removed)> wrote:

> s = strlen(str) ;
>
>Since strlen returns a size_t, we have a 64 bit result being
>assigned to a 32 bit int.
>
>This can be correct, and in 99.9999999999999999999999999%
>of the cases the string will be smaller than 2GB...


Clearly with strlen() the chance of it being an error is negligible.
And I think this is true other size_t->int assignments. For example,
int s = sizeof(whatever) is almost never a problem.

Ideally, I would suggest not generating a warning unless some option
is set for it. (There should always be a "maximally paranoid" option
to help track down obscure errors.) But that only applies to
size_t->int assignments. Other 64->32 assignments may be more likely to be
in error. At the point you generate the warning, can you still tell
that it's a size_t rather than some other 64-bit int type?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-29-2007
"Malcolm McLean" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "Malcolm McLean" <(E-Mail Removed)> writes:

[...]
>>> There's a very obvious answer to that one. As a compiler-writer, youa
>>> re in a position to do it.

>>
>> I presume the solution you're suggesting is to make int 64 bits. How
>> does this help? strlen() still returns size_t, and if int and size_t
>> are both 64 bits, there will still be size_t values that cannot be
>> stored in an int.
>>

> Yes, but then you'd need an extremely long string to break the code,
> so the warning can be suppressed with some confidence that it won't
> cause a malfunction.


That's assuming you're able to suppress the warning for 64-bit
unsigned to 64-bit signed conversions without supressing warnings for,
say, 8-bit unsigned to 8-bit signed conversions. I don't know of any
compiler that allow that kind of find-grained control.

It's better to fix the code. It's even better to write it correctly
in the first place.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-29-2007
In article <(E-Mail Removed). com>,
user923005 <(E-Mail Removed)> wrote:
>Make your default int 64 bits, and be done with it.
>Ought to be 64 bits on a 64 bit platform anyway.


A compiler for an existing operating system needs to fit in with the
system's libraries, so he may not have that choice.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-29-2007
In article <(E-Mail Removed)>,
Keith Thompson <(E-Mail Removed)> wrote:

>It's better to fix the code. It's even better to write it correctly
>in the first place.


But int s = sizeof(char *) is not broken, even though sizeof() returns
a size_t.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reinterpret_cast<std::size_t>(p) and reinterpret_cast<std::size_t&>() Alex Vinokur C++ 1 02-06-2011 07:48 AM
Casting from const pair<const unsigned char*, size_t>* to constpair<unsigned char*, size_t>* Alex Vinokur C++ 9 10-13-2008 05:05 PM
Re: for(size_t a=begin();a!=end();++a){} Chris \( Val \) C++ 2 07-14-2003 06:31 AM
Re: size_t ... standards Howard Hinnant C++ 5 06-30-2003 07:22 PM
Re: size_t ... standards Howard Hinnant C++ 0 06-29-2003 05:45 PM



Advertisments