size_t problems
jacob navia
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?
jacob
Malcolm McLean
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:46d5c46d$0$5108$ba4a...@news.orange.fr...
a position to do it.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Kenneth Brody
[... "64-bit compiler" with 64-bit size_t ...]
> 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?
Well, some people will probably claim that those hundreds of warnings
are a good thing, as strlen() returns size_t and not int. However,
if you are bombarded with hundreds of such warnings, many people will
simply start ignoring all of the warnings, and the "real" ones will
be lost in the noise.
Perhaps a flag that says "only display the first N instances of this
warning"?
Perhaps you could make int 64 bits as well?
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsA...@gmail.com>
Ben Pfaff
> 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.
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.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Keith Thompson
Why didn't you get the same warnings in 32-bit mode? If int and
size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values of
size_t that cannot be stored in an int. If the "narrowing conversion"
warning is based on the sizes of the type rather than the ranges, I'd
say you've just discovered a compiler bug.
If you're getting hundreds of warnings, it's because you have hundreds
of instances of potential loss of information.
Note that a conversion to a signed type of a value that doesn't fit in
that type yields an implementation-defined result (or, in C99, raises
an implementation-defined signal). In theory, the result could be
more than just a loss of information.
The problem is to distinguish cases where the conversion can't
actually overflow at execution times from the cases where it can.
Sufficiently clever dataflow analysis in the compiler might eliminate
some of the errors. If, given
int s = strlen(str);
the compiler knows enough about how the value of str that it can be
sure it's no longer than INT_MAX bytes, it can eliminate the warning.
But I don't know if it's practical, or even possible to eliminate
enough of the warnings this way. Doing this in most cases is hard;
doing it in all cases might be equivalent to solving the halting
problem. (That latter is only a guess.)
(Making int 64 bits won't solve the problem, since INT_MAX will still
be less than SIZE_MAX.)
You can filter the compiler's output to eliminate warnings about
narrowing implicit conversions (or, if available, use a compiler
option to turn off that particular warning), but that could miss cases
that could actually overflow.
In my opinion, the warnings are legitimate. The ideal solution is not
to suppress them, but to fix the code, assigning the result of
strlen() to a size_t rather than to an int. (Or I suppose you could
use a cast to shut up the compiler if you're *certain* the result can
never exceed INT_MAX, but that's not what I'd do.)
By compiling the code in 64-bit mode, you've discovered a number of
dormant bugs in the code.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <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"
Keith Thompson
> "jacob navia" <ja...@jacob.remcomp.fr> wrote in message
> news:46d5c46d$0$5108$ba4a...@news.orange.fr...
>>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.
--
Malcolm McLean
"Ben Pfaff" <b...@cs.stanford.edu> wrote in message
news:87lkbug...@blp.benpfaff.org...
> 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.
>
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.
Malcolm McLean
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnzm0aw...@nuthaus.mib.org...
warning can be suppressed with some confidence that it won't cause a
malfunction.
jacob navia
> Why didn't you get the same warnings in 32-bit mode? If int and
> size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values of
> size_t that cannot be stored in an int. If the "narrowing conversion"
> warning is based on the sizes of the type rather than the ranges, I'd
> say you've just discovered a compiler bug.
>
2GB strings are the most you can get under the windows schema in 32 bits.
> If you're getting hundreds of warnings, it's because you have hundreds
> of instances of potential loss of information.
>
Yes, "*POTENTIALLY*" I could be missing all those strings longer
than 4GB (!!!). But I do not care about those :-)
> Note that a conversion to a signed type of a value that doesn't fit in
> that type yields an implementation-defined result (or, in C99, raises
> an implementation-defined signal). In theory, the result could be
> more than just a loss of information.
>
Only for strings >2GB Keith. Let's keep it realistic!
> The problem is to distinguish cases where the conversion can't
> actually overflow at execution times from the cases where it can.
>
> Sufficiently clever dataflow analysis in the compiler might eliminate
> some of the errors. If, given
> int s = strlen(str);
> the compiler knows enough about how the value of str that it can be
> sure it's no longer than INT_MAX bytes, it can eliminate the warning.
> But I don't know if it's practical, or even possible to eliminate
> enough of the warnings this way. Doing this in most cases is hard;
> doing it in all cases might be equivalent to solving the halting
> problem. (That latter is only a guess.)
>
> (Making int 64 bits won't solve the problem, since INT_MAX will still
> be less than SIZE_MAX.)
>
> You can filter the compiler's output to eliminate warnings about
> narrowing implicit conversions (or, if available, use a compiler
> option to turn off that particular warning), but that could miss cases
> that could actually overflow.
>
> In my opinion, the warnings are legitimate. The ideal solution is not
> to suppress them, but to fix the code, assigning the result of
> strlen() to a size_t rather than to an int. (Or I suppose you could
> use a cast to shut up the compiler if you're *certain* the result can
> never exceed INT_MAX, but that's not what I'd do.)
>
> By compiling the code in 64-bit mode, you've discovered a number of
> dormant bugs in the code.
>
There isn't any string longer than a few K in this program!
Of course is a potential bug, but it is practically impossible!
jacob navia
> jacob navia <ja...@jacob.remcomp.fr> writes:
>
>> 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.
>
> 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.
The problem is that if I change those ints into size_t's they
are unsigned, and they will produce problems when comparing them with
signed quantities, making MORE modifications necessary in a cascade
of modifications that would surely introduce bugs...
I have *already* introduced (int)strlen(...) in many places...
jacob navia
???
(Please excuse my stupidity by I do not see it...)
christian.bau
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.
Malcolm McLean
> 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...)
>
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.
user923005
Make your default int 64 bits, and be done with it.
Ought to be 64 bits on a 64 bit platform anyway.
Kelsey Bjarnason
> "Ben Pfaff" <b...@cs.stanford.edu> wrote in message
> news:87lkbug...@blp.benpfaff.org...
>> 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.
user923005
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.
Keith Thompson
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnzm0aw...@nuthaus.mib.org...
>> "Malcolm McLean" <regn...@btinternet.com> 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.
Richard Tobin
jacob navia <ja...@jacob.remcomp.fr> 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.
user923005
> In article <46d5c46d$0$5108$ba4ac...@news.orange.fr>,
> jacob navia <ja...@jacob.remcomp.fr> 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?
I doubt that the chance a string is longer than 2GB is always
negligible.
Consider the characters 'C', 'T', 'A', 'G' in various combinations in
a long sequence of (say) 3 billion.
That's the human genome.
The Chrysanthemum genome is much bigger.
I know of people using database systems to do genetics research. The
probability of long character sequences on those systems is not
negligible.
If the machine is capable of handling large data, right away people
will start to do it.
Richard Tobin
user923005 <dco...@connx.com> 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 Tobin
Keith Thompson <ks...@mib.org> 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 Tobin
user923005 <dco...@connx.com> wrote:
>I doubt that the chance a string is longer than 2GB is always
>negligible.
"Always negligible" is irrelevant. Of course it's not negligible in
programs chosen to demonstrate the problem.
>Consider the characters 'C', 'T', 'A', 'G' in various combinations in
>a long sequence of (say) 3 billion.
>That's the human genome.
The chance of a given program being one that stores the complete human
genome in a string is negligible. People with such programs can set the
option I suggested.
Malcolm McLean
"Richard Tobin" <ric...@cogsci.ed.ac.uk> wrote in message
news:fb4r2u$2uhn$4...@pc-news.cogsci.ed.ac.uk...
> The chance of a given program being one that stores the complete human
> genome in a string is negligible. People with such programs can set the
> option I suggested.
>
Whilst generally you'd want a "rope" type-structure to handle such a long
sequence, there might well be reasons for storing the whole genome as a flat
string. Certainly if I had a 64-bit machine with enough memory installed, I
would expect to have the option, and I'd expect to be able to write the
program in regular C.
Keith Thompson
> Keith Thompson wrote:
>> Why didn't you get the same warnings in 32-bit mode? If int and
>> size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values of
>> size_t that cannot be stored in an int. If the "narrowing conversion"
>> warning is based on the sizes of the type rather than the ranges, I'd
>> say you've just discovered a compiler bug.
>
> 2GB strings are the most you can get under the windows schema in 32 bits.
Ok. Does your compiler know that?
Assigning an arbitrary size_t value to an object of type int, if both
types are 32 bits, could potentially overflow. Your compiler
apparently doesn't issue a warning in that case. Is it because it
knows that the value returned by strlen() can't exceed INT_MAX (if so,
well done, especially since it seems to be smart enough not to make
that assumption on a 64-bit system), or is it because it doesn't issue
a warning when both types are the same size?
For example:
size_t s = func(-1);
/* Assume func() takes a size_t argument and returns it.
Assume func() is defined in another translation unit,
so the compiler can't analyze its definition. In other
words, 's' is initialized to SIZE_MAX, but the compiler
can't make any assumptions about its value. */
signed char c = s;
/* Presumably this produces a warning. */
int i = s;
/* This is a potential overflow. Does this produce
a warning? Should it? */
If your compiler warns about the initialization of 'c' but not about
the initialization of 'i', then IMHO it's being inconsistent. This
doesn't address your original question, but it's related.
[...]
> There isn't any string longer than a few K in this program!
> Of course is a potential bug, but it is practically impossible!
You know that, and I know that, but what matters is what the compiler
knows.
Is it conceivable that a bug in the program and/or some unexpected
input could cause it to create a string longer than 2GB?
You asked how to suppress the bogus warnings without losing any valid
warnings. To do that, your compiler, or some other tool, has to be
able to tell the difference. Telling me that none of the strings are
longer than 2GB doesn't address that concern, unless you can convey
that knowledge to the compiler.
jacob navia
> In article <1188426076.4...@22g2000hsm.googlegroups.com>,
> user923005 <dco...@connx.com> wrote:
>
>> I doubt that the chance a string is longer than 2GB is always
>> negligible.
>
> "Always negligible" is irrelevant. Of course it's not negligible in
> programs chosen to demonstrate the problem.
>
>> Consider the characters 'C', 'T', 'A', 'G' in various combinations in
>> a long sequence of (say) 3 billion.
>> That's the human genome.
>
> The chance of a given program being one that stores the complete human
> genome in a string is negligible. People with such programs can set the
> option I suggested.
>
> -- Richard
The program has strings of at most a few K. It is an IDE (Integrated
development environment, debugger, etc)
An int can hold string lengths of more than 2 billion... MORE than
enough for this environment. This program has been running under 32 bit
windows where all user space is at most 2GB.
jacob navia
> In article <lnhcmiv...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> 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
If we use size_t everywhere, it is an UNSIGNED quantity.
This means that comparisons with signed quantities will provoke
other warnings, etc etc.
int s = strlen(str) is NOT broken.
Keith Thompson
> "jacob navia" <ja...@jacob.remcomp.fr> wrote in message
> news:46d5d579$0$27386$ba4a...@news.orange.fr...
>> 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.
One *shirt* fits all (unless somebody other than you actually wants
one).
> 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.
lcc-win32 (and presumably lcc-win64, if that's what it's called) is a
Windows compiler. jacob does not have the option of changing the
Windows API, and a compiler that's incompatible with the underlying
operating system isn't going to be very useful.
jacob navia
>
> "Richard Tobin" <ric...@cogsci.ed.ac.uk> wrote in message
> news:fb4r2u$2uhn$4...@pc-news.cogsci.ed.ac.uk...
>> The chance of a given program being one that stores the complete human
>> genome in a string is negligible. People with such programs can set the
>> option I suggested.
>>
> I work in that field.
> Whilst generally you'd want a "rope" type-structure to handle such a
> long sequence, there might well be reasons for storing the whole genome
> as a flat string. Certainly if I had a 64-bit machine with enough memory
> installed, I would expect to have the option, and I'd expect to be able
> to write the program in regular C.
>
YES SIR!
With my new lcc-win32 YOU WILL BE ABLE TO DO IT!
But I am not speaking of that program. I am speaking about
other programs I am PORTING from 32 bit, whose strings are never
bigger than a few Kbytes at most!
jacob navia
> lcc-win32 (and presumably lcc-win64, if that's what it's called) is a
> Windows compiler. jacob does not have the option of changing the
> Windows API, and a compiler that's incompatible with the underlying
> operating system isn't going to be very useful.
>
Yes. Mr Gates decided that
sizeof(int) == sizeof(long) == 4.
Only long long is 64 bits. PLease address alll flames to him.
NOT TO ME!!!
:-)
Keith Thompson
> Richard Tobin wrote:
>> In article <lnhcmiv...@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> 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.
>
> This means that comparisons with signed quantities will provoke
> other warnings, etc etc.
Perhaps those other signed quantities should have been unsigned as
well.
> int s = strlen(str) is NOT broken.
And yet the compiler you're using warns about it. Perhaps you should
take it up with the author of the compiler.
There may well be no easy way to address your problem. Re-writing all
the code as it should have been written in the first place (using
size_t to hold size_t values) may not be practical. Turning off
warnings that you know aren't necessary, while leaving other warnings
in place, requires conveying that information to the compiler; there
may not be a mechanism for doing so. Inserting hundreds of casts
could suppress the warnings, but I dislike that solution, and it's
still a substantial amount of work.
I suppose you could write a strlen wrapper that calls the real strlen,
checks whether the result exceeds INT_MAX (if you think that check is
worth doing), and then returns the result as an int. That's assuming
strlen calls are the only things triggering the warnings. And you'd
still have to make hundreds of changes in the code.
You know that the conversions aren't going to overflow, but C's type
system doesn't let you convey that knowledge to the compiler.
pete
Maybe the signed quantities should be unsigned?
--
pete
Martin Wells
jacob navia:
> 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.
<snip>
> 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?
Assuming that you've a shred of intelligence, I'm led to believe that
you suffer from "int syndrome".
"int syndrome" reminds me of old drivers, the kind of people who
always drive the canonical route somewhere. Even during rush-hour,
even at night when the streets are clear, they always take the same
route. I don't know if you'd call it stubbornness or stupidity. They
lack dynamic-ity.
These drivers remind me of the programmers who are "int" people. The
solution to your boggle is so blatantly oblivious that I'm not even
gonna mention what the solution is.
The real problem is why you feel so indoctrinated into using int,
especially places where you shouldn't be using it.
If you want advice though, I'd say use the appropriate types where
appropriate, and to edit any code that uses types wrongly.
Martin
CBFalconer
> Keith Thompson wrote:
>
>> Why didn't you get the same warnings in 32-bit mode? If int and
>> size_t are both 32 bits, INT_MAX < SIZE_MAX, and there are values
>> of size_t that cannot be stored in an int. If the "narrowing
>> conversion" warning is based on the sizes of the type rather than
>> the ranges, I'd say you've just discovered a compiler bug.
>
> 2GB strings are the most you can get under the windows schema in 32
> bits.
>
>> If you're getting hundreds of warnings, it's because you have
>> hundreds of instances of potential loss of information.
>
> Yes, "*POTENTIALLY*" I could be missing all those strings longer
> than 4GB (!!!). But I do not care about those :-)
That is precisely the sloppy attitude that has led to many bugs.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer
>
> 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.
>
> of the cases the string will be smaller than 2GB...
Simply define s as a long long or (better) as a size_t.
CBFalconer
>
... snip ...
>
> int s = strlen(str) is NOT broken.
Yes it is. How can you guarantee that strlen never returns a value
that exceeds the capacity of an int? However:
size_t s = strlen(str);
is NOT broken, assuming suitable #includes and definitions.
Keith Thompson
> jacob navia wrote:
> ... snip ...
>>
>> int s = strlen(str) is NOT broken.
>
> Yes it is. How can you guarantee that strlen never returns a value
> that exceeds the capacity of an int?
By never passing it a pointer to a string longer than INT_MAX
characters. This tends to be easier than, for example, guaranteeing
that 'x + y' will never overflow.
The declaration may or may not be broken, depending on what happens at
run time. The problem is that, apparently, the programmer knows it's
safe, but the compiler doesn't have enough information to prove it.
The ideal solution is to declare s as a size_t, and to make whatever
other code changes follow from that, but that's not always practical.
Ian Collins
Why would you want to assign an unsigned value to an int? Why do you
think it makes sense to have a negative size?
--
Ian Collins.
jacob navia
Because that int is used in many other contexts later, for instance
comparing it with other integers.
int len = strlen(str);
for (i=0; i<len; i++) {
/// etc
}
The i<len comparison would provoke a warning if len is unsigned...
jacob navia
Assuming that you have a shred of intelligence, you will be able
to understand this:
That int is used in many other contexts later, for instance
comparing it with other integers.
int i,len = strlen(str);
for (i=0; i<len; i++) {
/// etc
}
The i<len comparison would provoke a warning if len is unsigned...
If I make i unsigned too, then its usage within the loop will provoke
even more problems!
Richard Heathfield
> jacob navia wrote:
<snip>
>> int s = strlen(str) is NOT broken.
>
> Why would you want to assign an unsigned value to an int? Why do you
> think it makes sense to have a negative size?
Well, obviously it doesn't make any sense at all, and assigning strlen's
result to an int is clearly wrong; strlen yields size_t, not int.
On the other hand, does it really make sense to play with trolls?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Ian Collins
I may sound pedantic, but keeping signed and unsigned quantities apart
avoids nasty bugs.
--
Ian Collins.
Ian Collins
>
> That int is used in many other contexts later, for instance
> comparing it with other integers.
> int i,len = strlen(str);
>
> for (i=0; i<len; i++) {
> /// etc
> }
>
>
> The i<len comparison would provoke a warning if len is unsigned...
>
> If I make i unsigned too, then its usage within the loop will provoke
> even more problems!
Name one.
--
Ian Collins.
Ian Collins
>
> On the other hand, does it really make sense to play with trolls?
>
--
Ian Collins.
jacob navia
> Richard Heathfield wrote:
>> On the other hand, does it really make sense to play with trolls?
>>
> It beats work...
>
OK. You win. Will not answer any posts from you.
Ian Collins
Bad humour day today?
You normally stop once you realise I'm correct...
--
Ian Collins.
Thad Smith
> int s;
>
> // ...
> s = strlen(str) ;
>
> Since strlen returns a size_t, we have a 64 bit result being
> assigned to a 32 bit int.
...
> 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 suggest a warning switch for the 64 bit to 32 bit conversion separate
from warnings for other narrowing conversions.
--
Thad
Ben Pfaff
> Ian Collins wrote:
>> Why would you want to assign an unsigned value to an int? Why do you
>> think it makes sense to have a negative size?
>
> Because that int is used in many other contexts later, for instance
> comparing it with other integers.
> int len = strlen(str);
>
> for (i=0; i<len; i++) {
> /// etc
> }
>
>
> The i<len comparison would provoke a warning if len is unsigned...
Only if 'i' is declared as type 'int'. If you declare it to have
type 'size_t', you will not have a problem.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Richard Heathfield
Some people's pennies are in orbit.
jacob navia
> jacob navia <ja...@jacob.remcomp.fr> writes:
>
>> Ian Collins wrote:
>>> Why would you want to assign an unsigned value to an int? Why do you
>>> think it makes sense to have a negative size?
>> Because that int is used in many other contexts later, for instance
>> comparing it with other integers.
>> int len = strlen(str);
>>
>> for (i=0; i<len; i++) {
>> /// etc
>> }
>>
>>
>> The i<len comparison would provoke a warning if len is unsigned...
>
> Only if 'i' is declared as type 'int'. If you declare it to have
> type 'size_t', you will not have a problem.
Of course, but that will lead to MORE changes in a chain reaction
that looks quite dangerous...
Ben Pfaff
It is of course possible to run into problems. If you have code
that you know to work in a given environment, then you may not
want to fix it, because it may break that code in that same
environment if you fail to understand the consequences of the
series of changes. But in this case you're talking about moving
the code to a new environment anyhow (32- to 64-bit), in which
case the code has to be tested anew. The choice is then between
maintaining the old version and the new version separately, as
different pieces of code, or making sure that the fixed version
works in both environments. Most of the time, I'd choose the
latter.
Richard Heathfield
> jacob navia <ja...@jacob.remcomp.fr> writes:
>
>> Ben Pfaff wrote:
>>> jacob navia <ja...@jacob.remcomp.fr> writes:
<snip>
>>>> The i<len comparison would provoke a warning if len is unsigned...
>>>
>>> Only if 'i' is declared as type 'int'. If you declare it to have
>>> type 'size_t', you will not have a problem.
>>
>> Of course, but that will lead to MORE changes in a chain reaction
>> that looks quite dangerous...
>
> It is of course possible to run into problems.
It is also possible to steer clear of problems. The "chain reaction"
simply doesn't happen if everything has the right type to start off
with. And if it doesn't, the chain reaction is a good thing, not a bad
thing, because it reveals type misconceptions in the code.
CBFalconer
> CBFalconer <cbfal...@yahoo.com> writes:
>> jacob navia wrote:
>> ... snip ...
>>>
>>> int s = strlen(str) is NOT broken.
>>
>> Yes it is. How can you guarantee that strlen never returns a value
>> that exceeds the capacity of an int?
>
> By never passing it a pointer to a string longer than INT_MAX
> characters. This tends to be easier than, for example, guaranteeing
> that 'x + y' will never overflow.
>
> The declaration may or may not be broken, depending on what happens at
> run time. The problem is that, apparently, the programmer knows it's
> safe, but the compiler doesn't have enough information to prove it.
>
> The ideal solution is to declare s as a size_t, and to make whatever
> other code changes follow from that, but that's not always practical.
Which I said, and you snipped. Why?
Malcolm McLean
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:46d6676c$0$27368$ba4a...@news.orange.fr...
> Ben Pfaff wrote:
>
>> Only if 'i' is declared as type 'int'. If you declare it to have
>> type 'size_t', you will not have a problem.
>
> Of course, but that will lead to MORE changes in a chain reaction
> that looks quite dangerous...
>
In fact if you use size_t safely and consistently, virtually all ints need
to be size_t's. The committee have managed to produce a very far-reaching
change to the C language, simply though fixing up a slight problem in the
interface to malloc().
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Keith Thompson
> Keith Thompson wrote:
>> CBFalconer <cbfal...@yahoo.com> writes:
>>> jacob navia wrote:
>>> ... snip ...
>>>>
>>>> int s = strlen(str) is NOT broken.
>>>
>>> Yes it is. How can you guarantee that strlen never returns a value
>>> that exceeds the capacity of an int?
>>
>> By never passing it a pointer to a string longer than INT_MAX
>> characters. This tends to be easier than, for example, guaranteeing
>> that 'x + y' will never overflow.
>>
>> The declaration may or may not be broken, depending on what happens at
>> run time. The problem is that, apparently, the programmer knows it's
>> safe, but the compiler doesn't have enough information to prove it.
>>
>> The ideal solution is to declare s as a size_t, and to make whatever
>> other code changes follow from that, but that's not always practical.
>
> Which I said, and you snipped. Why?
Sorry, I didn't realize I was repeating some of what you said.
Richard
> Ben Pfaff said:
>
>> jacob navia <ja...@jacob.remcomp.fr> writes:
>>
>>> Ben Pfaff wrote:
>>>> jacob navia <ja...@jacob.remcomp.fr> writes:
> <snip>
>>>>> The i<len comparison would provoke a warning if len is unsigned...
>>>>
>>>> Only if 'i' is declared as type 'int'. If you declare it to have
>>>> type 'size_t', you will not have a problem.
>>>
>>> Of course, but that will lead to MORE changes in a chain reaction
>>> that looks quite dangerous...
>>
>> It is of course possible to run into problems.
>
> It is also possible to steer clear of problems. The "chain reaction"
> simply doesn't happen if everything has the right type to start off
> with. And if it doesn't, the chain reaction is a good thing, not a bad
> thing, because it reveals type misconceptions in the code.
Ridiculous. Everything doesn't have the "right type" to start
with. Hence the chain reaction.
Millions of programmers the world over use int as a size store for
strings they know to be only a "few bytes" long. It might not be "right"
now, but there is a huge legacy of it.
A chain reaction of this type in a huge legacy code base could cause
all sorts of side effects. You tell the head of QA that moving from int
to size_t will "just work". Not in the real world it doesn't.
christian.bau
> jacob navia wrote:
> > Ian Collins wrote:
> >> jacob navia wrote:
> >>> Richard Tobin wrote:
> >>>> Keith Thompson <ks...@mib.org> 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
> >>> If we use size_t everywhere, it is an UNSIGNED quantity.
> >>> This means that comparisons with signed quantities will provoke
> >>> other warnings, etc etc.
>
> >>> int s = strlen(str) is NOT broken.
>
> >> Why would you want to assign an unsigned value to an int? Why do you
> >> think it makes sense to have a negative size?
>
> > Because that int is used in many other contexts later, for instance
> > comparing it with other integers.
> > int len = strlen(str);
>
> > for (i=0; i<len; i++) {
> > /// etc
> > }
>
> Why would you want a signed loop index for a zero to unsigned range?
>
> I may sound pedantic, but keeping signed and unsigned quantities apart
> avoids nasty bugs.
for (i = strlen (s) - 1; i >= 0; --i) ...
loops through all characters in a string in reverse order, as long as
the length of s is not excessive, if i is a signed 32 bit or longer
integer. Now write that with an unsigned type without any convoluted
code.
Malcolm McLean
"christian.bau" <christ...@cbau.wanadoo.co.uk> wrote in message
news:1188467715.7...@r29g2000hsg.googlegroups.com...
while(i--)
{
/* loop body */
CBFalconer
>
... snip ...
>
> comparing it with other integers.
>
> int i,len = strlen(str);
>
> for (i=0; i<len; i++) {
> /// etc
> }
>
> The i<len comparison would provoke a warning if len is unsigned...
>
> If I make i unsigned too, then its usage within the loop will
> provoke even more problems!
Why? Nothing can create a problem unless you pass its value to an
int, and that value is outside the range that that int can
express. If that happens, lo, you have found a bug. Meanwhile you
have the opportunity to use shift operations on it, to overflow it
without creating unsomething situations, etc.
CBFalconer
No, that will eventually lead to more accurate code with fewer
concealed traps. This is C, not B. The fact that you ignore all
these recommendations is a strong indication that your code is not
safe to use.
CBFalconer
> Ian Collins said:
>> jacob navia wrote:
>
> <snip>
>
>>> int s = strlen(str) is NOT broken.
>>
>> Why would you want to assign an unsigned value to an int? Why do
>> you think it makes sense to have a negative size?
>
> Well, obviously it doesn't make any sense at all, and assigning
> strlen's result to an int is clearly wrong; strlen yields size_t,
> not int.
>
> On the other hand, does it really make sense to play with trolls?
Now that is not fair. Yes, Jacob has peculiar (and many are
unsound) ideas, but that does not make him a troll. He seems to
have co-operated on advertising his compiler, for example, without
specifically acknowledgeing so doing.
CBFalconer
>
... snip ...
>
> comparing it with other integers.
>
> int len = strlen(str);
>
> for (i=0; i<len; i++) {
> /// etc
> }
>
> The i<len comparison would provoke a warning if len is unsigned...
I fail to see any reason why that 'i' should not be declared as
unsigned. Well, maybe extreme laziness.
CBFalconer
> Ian Collins said:
>> jacob navia wrote:
>>> Ian Collins wrote:
>>>> Richard Heathfield wrote:
>>>>
>>>>> On the other hand, does it really make sense to play with trolls?
>>>>>
>>>> It beats work...
>>>>
>>>
>>> OK. You win. Will not answer any posts from you.
>>
>> Bad humour day today?
>>
>> You normally stop once you realise I'm correct...
>
> Some people's pennies are in orbit.
That sounds like a pure Britticism. I suspect a connection with
pay-toilets of bygone days. Is a British penny still roughly one
nautical mile in diameter?
CBFalconer
>
>> I may sound pedantic, but keeping signed and unsigned quantities
>> apart avoids nasty bugs.
>
> for (i = strlen (s) - 1; i >= 0; --i) ...
>
> loops through all characters in a string in reverse order, as long
> as the length of s is not excessive, if i is a signed 32 bit or
> longer integer. Now write that with an unsigned type without any
> convoluted code.
for (i = strlen(s), j = i-1; i; j = i--) {
.... s[j] ....
pete
Well done!
--
pete
Richard Heathfield
> Richard Heathfield wrote:
>> Ian Collins said:
>>> jacob navia wrote:
>>>> Ian Collins wrote:
>>>>> Richard Heathfield wrote:
>>>>>
>>>>>> On the other hand, does it really make sense to play with trolls?
>>>>>>
>>>>> It beats work...
>>>>>
>>>>
>>>> OK. You win. Will not answer any posts from you.
>>>
>>> Bad humour day today?
>>>
>>> You normally stop once you realise I'm correct...
>>
>> Some people's pennies are in orbit.
>
> That sounds like a pure Britticism.
Well, if you'll pardon the expression, I coined it myself especially for
this thread. And yes, I'm British. So I suppose you're right.
> I suspect a connection with pay-toilets of bygone days.
No, none.
> Is a British penny still roughly one nautical mile in diameter?
No, and it never has been.
Richard Heathfield
<snip>
> Yes, Jacob has peculiar (and many are
> unsound) ideas, but that does not make him a troll.
The only alternative I can envisage is that he is utterly brainless. Is
that the theory you prefer?
Look at the facts. We've spent years trying to educate him in the
basics, and failed. If we were unfortunate enough to hire someone like
that, we'd have given him up as a bad job years ago and shuffled him
off into marketing (if we lacked the gumption to sack him outright). We
certainly wouldn't let him anywhere near our compiler-writing division.
Peter J. Holzer
> jacob navia wrote:
>> That int is used in many other contexts later, for instance
>> comparing it with other integers.
>>
>> int i,len = strlen(str);
>>
>> for (i=0; i<len; i++) {
>> /// etc
>> }
>>
>> The i<len comparison would provoke a warning if len is unsigned...
>>
>> If I make i unsigned too, then its usage within the loop will
>> provoke even more problems!
>
> Why? Nothing can create a problem unless you pass its value to an
> int, and that value is outside the range that that int can
> express.
No. Comparison with signed int also creates problems.
int i = -5;
unsigned u = 5;
if (i > u) printf("Gotcha!\n");
A C programmer should be aware of this when writing code. But if you
change types in existing code, something like that is easy to miss.
Of course Jacob already wrote that his compiler warns about this
problem, so he'll just have to change the type of the next variable or
add a cast.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Peter J. Holzer
> "Richard Tobin" <ric...@cogsci.ed.ac.uk> wrote in message
> news:fb4r2u$2uhn$4...@pc-news.cogsci.ed.ac.uk...
>> The chance of a given program being one that stores the complete human
>> genome in a string is negligible. People with such programs can set the
>> option I suggested.
>>
> I work in that field.
> Whilst generally you'd want a "rope" type-structure to handle such a long
> sequence, there might well be reasons for storing the whole genome as a flat
> string. Certainly if I had a 64-bit machine with enough memory installed, I
> would expect to have the option, and I'd expect to be able to write the
> program in regular C.
Nothing Richard wrote would prevent you from writing your programs in
regular C. All he suggested was that you should be able to turn off the
warning "64 bit value assigned to 32 bit variable" independently from
other "wide value assigned to narrow variable" warnings.
Peter J. Holzer
> In article <46d5c46d$0$5108$ba4a...@news.orange.fr>,
> jacob navia <ja...@jacob.remcomp.fr> wrote:
>
>> s = strlen(str) ;
>>
>>Since strlen returns a size_t, we have a 64 bit result being
>>assigned to a 32 bit int.
>>
>>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.
Since sizeof(whatever) can be evaluated at compile time (except
when a variable length array is involved), the compiler can even know
exactly when it is a problem.
Philip Potter
> Richard Heathfield wrote:
>> Some people's pennies are in orbit.
>
> That sounds like a pure Britticism.
I suspect after a while you'll understand what RH was referring to, and the
low-value copper coinage will descend.
Phil
--
Philip Potter pgp <at> doc.ic.ac.uk
Richard Heathfield
<snip>
> Comparison with signed int also creates problems.
>
> int i = -5;
> unsigned u = 5;
> if (i > u) printf("Gotcha!\n");
Indeed. Nevertheless, we must ask why values of two different types are
being compared in this way. Which is greater, half a pound of cheese or
a dozen eggs?
Richard Tobin
Ian Collins <ian-...@hotmail.com> wrote:
>> int s = strlen(str) is NOT broken.
>Why would you want to assign an unsigned value to an int? Why do you
>think it makes sense to have a negative size?
There are lots of reasons to assign an unsigned value to an int. Most
notably, so that you can do integer arithmetic on it. Do you really
want all array subscript variables to be size_t? If so, you'll have
to consider casting them if, say, you want to subtract one from
another.
-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Ben Bacarisse
> "jacob navia" <ja...@jacob.remcomp.fr> wrote in message
> news:46d6676c$0$27368$ba4a...@news.orange.fr...
>> Ben Pfaff wrote:
>>
>>> Only if 'i' is declared as type 'int'. If you declare it to have
>>> type 'size_t', you will not have a problem.
>>
>> Of course, but that will lead to MORE changes in a chain reaction
>> that looks quite dangerous...
>>
> Now you are realising the problem.
> In fact if you use size_t safely and consistently, virtually all ints
> need to be size_t's. The committee have managed to produce a very
> far-reaching change to the C language, simply though fixing up a
> slight problem in the interface to malloc().
One last time, maybe? size_t *fixes* a problem. The solution is not
without pain in legacy code, but size_t is _over 17 years old_ now.
You create a problem when you write a book, ostensibly for beginners,
that perpetuates the problems of legacy code! Your excellent post in
an other thread, shows that many of the "problems" with unsigned sizes
are figments (counting down an unsigned value).
You have no solution to offer anyone. 64 bit ints won't wash (for
Jabob Navia's problem) until MS buys the T-shirt, and not doing
anything would have caused just as many, of not more, problems in the
last 18 years. Taking pot-shots and an imperfect solution is one
thing, but you have to come up with something constructive to be taken
seriously.
--
Ben.
Ben Pfaff
> In fact if you use size_t safely and consistently, virtually all ints
> need to be size_t's. The committee have managed to produce a very
> far-reaching change to the C language, simply though fixing up a
> slight problem in the interface to malloc().
My code does in fact end up using size_t quite often. If I were
perfectly consistent, it would probably use size_t even more
often. Why is that a problem?
--
Ben Pfaff
http://benpfaff.org
Bart
> Peter J. Holzer said:
>
> <snip>
>
> > Comparison with signed int also creates problems.
>
> > int i = -5;
> > unsigned u = 5;
> > if (i > u) printf("Gotcha!\n");
>
> Indeed. Nevertheless, we must ask why values of two different types are
> being compared in this way. Which is greater, half a pound of cheese or
> a dozen eggs?
Not quite the same. If I have a container that can hold 0 to 12 eggs
and another that can hold (use some imagination) -6 to 6 eggs, it's
easy enough to compare say 4 in one with +3 in the other (the first
will make a bigger omelette).
I don't see a problem in comparing 0..12 with -6..6. Of course to
implement such a thing in a machine it may be necessary to do some
conversion first (such as both move sets of eggs to boxes that can
hold -6 to 12).
Bart
Ed Jensen
> It is also possible to steer clear of problems. The "chain reaction"
> simply doesn't happen if everything has the right type to start off
> with. And if it doesn't, the chain reaction is a good thing, not a bad
> thing, because it reveals type misconceptions in the code.
Just out of curiosity, what was the rationale behind having strlen()
return size_t instead of "int" or "unsigned int" in the first place?
Kenny McCormack
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
...
>You have no solution to offer anyone. 64 bit ints won't wash (for
>Jabob Navia's problem) until MS buys the T-shirt, and not doing
>anything would have caused just as many, of not more, problems in the
>last 18 years. Taking pot-shots and an imperfect solution is one
>thing, but you have to come up with something constructive to be taken
>seriously.
Like you??? (And Default Loser - both of you just post carp)
Richard Heathfield
> If I have a container that can hold 0 to 12 eggs
> and another that can hold (use some imagination) -6 to 6 eggs, it's
> easy enough to compare say 4 in one with +3 in the other (the first
> will make a bigger omelette).
Let's just say I'm suffering from imaginatrophy, shall we? The problem
here is not the negative value itself, but the comparison between a
value of a type that can store negative values and a value of a type
that cannot. These are fundamentally different concepts.
Richard Heathfield
The Rationale is silent on the matter of strlen (except for a cross-ref
to size_t). The size_t rationale can be found here:
http://www.lysator.liu.se/c/rat/c3.html#3-3-3-4
Ben Bacarisse
> both of you just post carp
Fishing for compliments?
--
Ben.
Richard Heathfield
That comment was out of plaice.
Charlton Wilbur
RH> Let's just say I'm suffering from imaginatrophy, shall we? The
RH> problem here is not the negative value itself, but the
RH> comparison between a value of a type that can store negative
RH> values and a value of a type that cannot. These are
RH> fundamentally different concepts.
Something I find myself considering frequently: do I have more dollars
in my wallet or in my debit card account? It's impossible for me to
have less than zero dollars in my wallet (although zero is
depressingly frequent), but it's entirely possible, as I have a line
of credit, to have less than zero dollars in my bank account.
The amount of money in my wallet is inherently an unsigned value; the
amount of money in my bank account is inherently a signed value.
Comparisons between them happen several times a week.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Richard Tobin
Richard Heathfield <r...@see.sig.invalid> wrote:
>Let's just say I'm suffering from imaginatrophy, shall we? The problem
>here is not the negative value itself, but the comparison between a
>value of a type that can store negative values and a value of a type
>that cannot. These are fundamentally different concepts.
Sizes and array subscripts are naturally connected, and often used
together in expressions. Array subscripts in C can be negative.
strlen() can't return a negative value, but it may make perfect sense
to compare its result with a subscript that can be negative, since it
is the subscript of the nul character at the end of the string.
Suppose s points to some interesting position in the middle of a
string, and s[t] is some other interesting position which may be
before or after s (so t is a signed integer). Why shouldn't I compare
t with strlen(s) to see whether it's before the end of the string?
There would be absolutely no problem using a signed type for sizes if
that type were big enough. Unfortunately, the natural signed type
*isn't* always big enough.
Richard Heathfield
>>>>>> "RH" == Richard Heathfield <r...@see.sig.invalid> writes:
>
> RH> Let's just say I'm suffering from imaginatrophy, shall we? The
> RH> problem here is not the negative value itself, but the
> RH> comparison between a value of a type that can store negative
> RH> values and a value of a type that cannot. These are
> RH> fundamentally different concepts.
>
> Something I find myself considering frequently: do I have more dollars
> in my wallet or in my debit card account? It's impossible for me to
> have less than zero dollars in my wallet (although zero is
> depressingly frequent), but it's entirely possible, as I have a line
> of credit, to have less than zero dollars in my bank account.
But you don't have /any/ dollars in your bank account. What you have is
a number which represents a dollar /balance/ - it is, if you like, the
difference between the number of dollars the bank owes you and the
number of dollars you owe the bank. It can, however, reasonably be
regarded as a monetary amount, and as such can of course be negative.
The number of dollars in your wallet is /also/ a monetary amount, and
monetary amounts can be negative. Of course, the number of dollars in
your wallet cannot be negative, any more than 6 can be negative, even
though 6 is an int and ints can be negative.
Kenneth Brody
>
> In article <lnhcmiv...@nuthaus.mib.org>,
> Keith Thompson <ks...@mib.org> 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.
What happens if sizeof(char *) doesn't fit in an int? (Okay, I don't
expect any real world system to exist for which that is true. But,
does the standard say that sizeof must fit in an int? And if so, why
return a size_t?)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsA...@gmail.com>
Martin Wells
> Assuming that you have a shred of intelligence, you will be able
> to understand this:
>
> That int is used in many other contexts later, for instance
> comparing it with other integers.
> int i,len = strlen(str);
>
> for (i=0; i<len; i++) {
> /// etc
>
> }
>
> The i<len comparison would provoke a warning if len is unsigned...
>
> If I make i unsigned too, then its usage within the loop will provoke
> even more problems!
See you're not really looking for a solution at all, but rather a band-
aid to place over the gaping wound.
If you want to trully fix the code, then re-write it PROPERLY.
You might choose "unsigned" over "size_t" if you're EXTREMELY speed-
conscious, even though there'll only be a difference on machines where
"size_t" is bigger than the most efficient integer type. You'll have
to make sure though that the string length will always be within
range. In any way, it should have been written as:
unsigned x = (unsigned)strlen(my_string);
The purpose of the cast would be to suppress a compiler warning.
As for using "int" as a loop counter, I don't see why you'd use a
signed integer type for that purpose (other than "int syndrome" of
course).
Martin
Martin Wells
> Millions of programmers the world over use int as a size store for
> strings they know to be only a "few bytes" long. It might not be "right"
> now, but there is a huge legacy of it.
And that's perfectly OK if they make sure the number will never be too
high.
However, they'd want a cast to suppress compiler warnings.
Martin
Martin Wells
> You tell the head of QA that moving from int
> to size_t will "just work". Not in the real world it doesn't.
When used properly it works perfectly.
Martin
Ben Pfaff
But that's the problem: if it was used properly, then you
wouldn't have to make the change. The fact that you have to
change it means that related code is likely to make bad related
assumptions.
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield
CBFalconer
> CBFalconer said:
>
> <snip>
>
>> Yes, Jacob has peculiar (and many are
>> unsound) ideas, but that does not make him a troll.
>
> The only alternative I can envisage is that he is utterly brainless.
> Is that the theory you prefer?
I'm just dealing with facts. Let him pick the theory under which
he exists around here. Words and actions count.
>
> Look at the facts. We've spent years trying to educate him in the
> basics, and failed. If we were unfortunate enough to hire someone
> like that, we'd have given him up as a bad job years ago and
> shuffled him off into marketing (if we lacked the gumption to sack
> him outright). We certainly wouldn't let him anywhere near our
> compiler-writing division.
Without supervision, yes. This leaves him apparently peculiar.
Maybe he is a big act.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
>> jacob navia wrote:
>>
>>> That int is used in many other contexts later, for instance
>>> comparing it with other integers.
>>>
>>> int i,len = strlen(str);
>>>
>>> for (i=0; i<len; i++) {
>>> /// etc
>>> }
>>>
>>> The i<len comparison would provoke a warning if len is unsigned...
>>>
>>> If I make i unsigned too, then its usage within the loop will
>>> provoke even more problems!
>>
>> Why? Nothing can create a problem unless you pass its value to an
>> int, and that value is outside the range that that int can
>> express.
>
> No. Comparison with signed int also creates problems.
But you don't do that, and if you do the compiler should warn.
Things of different types shouldn't be compared, and is unnecessary
(unless you mis-type variables).
CBFalconer
> CBFalconer said:
>
>
>> Is a British penny still roughly one nautical mile in diameter?
>
> No, and it never has been.
It was when I was last there mumble years ago. Roughly 1 inch
diameter, thick, and two or three in your pocket would tear holes
in the presence of gravity. Much like smoke tests of equipment.
Richard Heathfield
> Richard Heathfield wrote:
>> CBFalconer said:
>>
> ... snip ...
>>
>>> Is a British penny still roughly one nautical mile in diameter?
>>
>> No, and it never has been.
>
> It was when I was last there mumble years ago.
No, it wasn't.
> Roughly 1 inch diameter,
That's a good four orders of magnitude - almost five - away from being a
nautical mile.
user923005
> Richard Heathfield wrote:
> > Ian Collins said:
> >> jacob navia wrote:
>
> > <snip>
>
> >>> int s = strlen(str) is NOT broken.
>
> >> Why would you want to assign an unsigned value to an int? Why do
> >> you think it makes sense to have a negative size?
>
> > strlen's result to an int is clearly wrong; strlen yields size_t,
> > not int.
>
> > On the other hand, does it really make sense to play with trolls?
>
> Now that is not fair. Yes, Jacob has peculiar (and many are
> unsound) ideas, but that does not make him a troll. He seems to
> have co-operated on advertising his compiler, for example, without
> specifically acknowledgeing so doing.
There have been other posters who (over time) became more and more
sensible.
In fact, that should happen to all of us, and it should be an ongoing
process (never coming to completion because none of us are perfect).
Now, I sometimes disagree with Jacob, but I think he makes an honest
attempt to communicate most of the time. Though he may often be
'contrary' I would not label him as a troll.
For my way of thinking, a troll has no interest in information. He
just wants to do something controversial and then sit back and laugh
at the reactions. Either that, or they are mentally ill and are
incapable of intelligent exchange of information. In my opinion,
Jacob Navia is not of either sort.
user923005
The result of a sizeof () operator is a size_t.
Can you imagine any object which has a negative size?
A size_t can describe the size of any object allowed by the C
language. An int cannot.
What if objects larger than unsigned are allowed by a compiler
implementation?
It is not unlikely that int and unsigned int are 32 bits on some
implementation on 64 bit hardware.
Would you want to be able to allocate an array of 20 GB if you needed
it? In such an instance, an unsigned integer would not work but a
size_t could work.
Can you imagine a better thing to return than a size_t?
Summary:
An int is a defective return from anything that describes the size of
an object.
An unsigned is a defective return from anything that describes the
size of an object.
A size_t is the perfect return from anything that describes the size
of an object.
I try to always use size_t both for object dimentions and array
addressing (though I admit I am not totally rigorous about it).
Joe Wright
> CBFalconer said:
>
>> Richard Heathfield wrote:
>>> CBFalconer said:
>>>
>> ... snip ...
>>>> Is a British penny still roughly one nautical mile in diameter?
>>> No, and it never has been.
>> It was when I was last there mumble years ago.
>
> No, it wasn't.
>
>> Roughly 1 inch diameter,
>
> That's a good four orders of magnitude - almost five - away from being a
> nautical mile.
>
6,080 feet or 72,960 inches. That would be a 'Pretty' penny indeed.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Richard Tobin
Kenneth Brody <kenb...@spamcop.net> wrote:
>What happens if sizeof(char *) doesn't fit in an int?
Then you should get a different computer.
>(Okay, I don't
>expect any real world system to exist for which that is true. But,
>does the standard say that sizeof must fit in an int? And if so, why
>return a size_t?)
No, and it commonly doesn't. But not all programs have to handle
objects that big.
Ed Jensen
> An int is a defective return from anything that describes the size of
> an object.
And yet, other programming languages get by -- somehow -- by returning
an integer when asked for the length of a string.
> An unsigned is a defective return from anything that describes the
> size of an object.
And yet, other programming languages get by -- somehow -- even though
they don't even have unsigned integer types.
> A size_t is the perfect return from anything that describes the size
> of an object.
I recognize and understand why the range of C types are defined the
way they're defined, but that doesn't minimize the pain when trying to
write 100% portable code.
CBFalconer
> Ian Collins <ian-...@hotmail.com> wrote:
>
>>> int s = strlen(str) is NOT broken.
>
>> Why would you want to assign an unsigned value to an int? Why
>> do you think it makes sense to have a negative size?
>
> Most notably, so that you can do integer arithmetic on it. Do
> you really want all array subscript variables to be size_t? If
> so, you'll have to consider casting them if, say, you want to
> subtract one from another.
Not if you don't get a negative result. You can easily avoid this
by applying the complex test "if (szt1 > szt2) ... else ...".
CBFalconer
> Bart said:
>
>> If I have a container that can hold 0 to 12 eggs and another that
>> can hold (use some imagination) -6 to 6 eggs, it's easy enough to
>> compare say 4 in one with +3 in the other (the first will make a
>> bigger omelette).
>
> Let's just say I'm suffering from imaginatrophy, shall we? The
> problem here is not the negative value itself, but the comparison
> between a value of a type that can store negative values and a value
> of a type that cannot. These are fundamentally different concepts.
However we can compare the "count of items in the bins",
eliminating the dependance on what the items actually are. This
corresponds to casting in some form or another, and carries its own
dangers.