469,326 Members | 1,576 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,326 developers. It's quick & easy.

size_t problems

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?

jacob
Aug 29 '07
409 9568
jacob navia wrote:
>
.... snip ...
>
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...
I fail to see any reason why that 'i' should not be declared as
unsigned. Well, maybe extreme laziness.

--
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

Aug 30 '07 #51
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. I suspect a connection with
pay-toilets of bygone days. Is a British penny still roughly one
nautical mile in diameter?

--
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

Aug 30 '07 #52
CBFalconer said:
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 <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
Aug 30 '07 #53
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?

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.

--
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
Aug 30 '07 #54
On 2007-08-30 09:49, CBFalconer <cb********@yahoo.comwrote:
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.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Aug 30 '07 #55
On 2007-08-29 22:05, Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>> 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.
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.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Aug 30 '07 #56
On 2007-08-29 22:35, Malcolm McLean <re*******@btinternet.comwrote:
"Richard Tobin" <ri*****@cogsci.ed.ac.ukwrote in message
news:fb***********@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.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Aug 30 '07 #57
CBFalconer wrote:
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 <atdoc.ic.ac.uk
Aug 30 '07 #58
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?

--
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
Aug 30 '07 #59
In article <5j***********@mid.individual.net>,
Ian Collins <ia******@hotmail.comwrote:
>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.
Aug 30 '07 #60
"Malcolm McLean" <re*******@btinternet.comwrites:
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46***********************@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.
Aug 30 '07 #61
"Malcolm McLean" <re*******@btinternet.comwrites:
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
Aug 30 '07 #62
On Aug 30, 2:21 pm, Richard Heathfield <r...@see.sig.invalidwrote:
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

Aug 30 '07 #63
Richard Heathfield <rj*@see.sig.invalidwrote:
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?
Aug 30 '07 #64
In article <87************@bsb.me.uk>,
Ben Bacarisse <be********@bsb.me.ukwrote:
....
>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)

Aug 30 '07 #65
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.

--
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
Aug 30 '07 #66
Ed Jensen said:
Richard Heathfield <rj*@see.sig.invalidwrote:
>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?
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

--
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
Aug 30 '07 #67
ga*****@xmission.xmission.com (Kenny McCormack) writes:
both of you just post carp
Fishing for compliments?

--
Ben.
Aug 30 '07 #68
Ben Bacarisse said:
ga*****@xmission.xmission.com (Kenny McCormack) writes:
>both of you just post carp

Fishing for compliments?
That comment was out of plaice.

--
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
Aug 30 '07 #69
>>>>"RH" == Richard Heathfield <rj*@see.sig.invalidwrites:

RHLet's just say I'm suffering from imaginatrophy, shall we? The
RHproblem here is not the negative value itself, but the
RHcomparison between a value of a type that can store negative
RHvalues and a value of a type that cannot. These are
RHfundamentally 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
cw*****@chromatico.net
Aug 30 '07 #70
In article <Cc******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Aug 30 '07 #71
Charlton Wilbur said:
>>>>>"RH" == Richard Heathfield <rj*@see.sig.invalidwrites:

RHLet's just say I'm suffering from imaginatrophy, shall we? The
RHproblem here is not the negative value itself, but the
RHcomparison between a value of a type that can store negative
RHvalues and a value of a type that cannot. These are
RHfundamentally 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.

--
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
Aug 30 '07 #72
Richard Tobin wrote:
>
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
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:Th*************@gmail.com>
Aug 30 '07 #73
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!

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

Aug 30 '07 #74
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

Aug 30 '07 #75
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

Aug 30 '07 #76
Martin Wells <wa****@eircom.netwrites:
>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.
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
Aug 30 '07 #77
"Peter J. Holzer" wrote:
CBFalconer <cb********@yahoo.comwrote:
>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).

--
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

Aug 30 '07 #78
Richard Heathfield wrote:
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

Aug 30 '07 #79
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. 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.

--
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

Aug 30 '07 #80
On Aug 30, 2:40 am, CBFalconer <cbfalco...@yahoo.comwrote:
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?
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.
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.

Aug 30 '07 #81
On Aug 30, 9:14 am, Ed Jensen <ejen...@visi.comwrote:
Richard Heathfield <r...@see.sig.invalidwrote:
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?
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).

Aug 30 '07 #82
In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:
>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.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Aug 30 '07 #83
user923005 <dc*****@connx.comwrote:
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.
Aug 30 '07 #84
Richard Heathfield wrote:
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.

--
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

Aug 30 '07 #85
Richard Tobin wrote:
Ian Collins <ia******@hotmail.comwrote:
>>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.
Not if you don't get a negative result. You can easily avoid this
by applying the complex test "if (szt1 szt2) ... else ...".

--
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

Aug 30 '07 #86
On Aug 30, 2:15 pm, Ed Jensen <ejen...@visi.comwrote:
user923005 <dcor...@connx.comwrote:
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.
Can those same languages create objects with a size to large to be
held in an integer?
If 'yes', then those languages are defective. If 'no', then integer
is the correct return.
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.
I can create a language with a single type. Somehow, I think it will
be less effective than C for programming tasks.
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.
The way to minimize the pain of writing 100% portable code is to write
it correctly, according to the language standard. For instance, that
would include using size_t for object sizes. Now, pre-ANSI C did not
have size_t. So that code will require effort to repair.
Aug 30 '07 #87
Ed Jensen <ej*****@visi.comwrites:
user923005 <dc*****@connx.comwrote:
>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.
What programming languages are you thinking of here?
--
"Am I missing something?"
--Dan Pop
Aug 30 '07 #88
On Aug 30, 5:42 pm, Richard Heathfield <r...@see.sig.invalidwrote:
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.
Possibly, but comparing two such values is still meaningful. Try
adding +6 to the numbers in my little example and both values must now
be positive and can be compared a little more easily. There's still a
question of overflow but that's a different problem.

Signed/unsigned numbers have different ranges. Why is it a big deal to
compare these two types of values? Is it because one type can store a
value that does not exist in the other? That's also a problem with
short and long ints. Anyway the solution can be simple, such as
converting the numbers into a type that accommodates both ranges.

Bart C

Aug 30 '07 #89
user923005 wrote:
>
.... snip ...
>
A size_t can describe the size of any object allowed by the C
language. An int cannot.
In the interests of accuracy, a size_t is guaranteed to describe
those sizes. An int is not guaranteed to have similar capability,
however it may in some systems.

--
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

Aug 30 '07 #90

Ed Jensen:
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.
It's considerably painless, even fun, if you make it your religion
from the very start.

Martin

Aug 30 '07 #91
>>>>"BP" == Ben Pfaff <bl*@cs.stanford.eduwrites:

BPEd Jensen <ej*****@visi.comwrites:
> And yet, other programming languages get by -- somehow -- even
though they don't even have unsigned integer types.
BPWhat programming languages are you thinking of here?

Perl, where one has to dig into internals to determine whether a
scalar variable is a number or a string and whether a number is an
integer or a floating-point value.

Scheme, where the important distinction is not signed or unsigned, but
exact or inexact.

Those are just two I can think of off the top of my head. I'm sure
there are more.

Charlton


--
Charlton Wilbur
cw*****@chromatico.net
Aug 30 '07 #92

Keith Thompson:
I'm not saying that you'd necessarily make this particular mistake.
But adding a cast to silence a warning should be thought of as a
fairly drastic step, and it should be very carefully considered.
I know what you're saying and I agree with you: If you're gonna be
suppressing warnings through the use of casts then you'd better be
certain about what you're doing.

Of course though, in the hands of a competant programmer, the use of
casts to suppress warnings can be quite useful. I've done it quite a
few times, both in C and in C++. Here might be an example in fully
portable code:

char NumToDigit(unsigned const x)
{
assert( x >= 0 && x <= 9 ); /* Let's assume that we'll never get
bad input */

return (char)('0' + x); /* No warning, yippee! */
}

A note to those who don't fully understand integer promotion yet:

1: '0' is promoted to type "unsigned" before it's added to x.
2: The result of the addition is put into a char, but we shouldn't get
a truncation warning because we've explictly used a cast.

Martin

Aug 30 '07 #93
Keith Thompson:
A lot of newbie C programmers will write something like:

int *ptr = malloc(100 * sizeof(int));

and then change it to

int *ptr = (int*)malloc(100 * sizeof(int));

because the compiler warned them about a type mismatch on the
initialization. In fact, the compiler's warning was correct, and the
cast merely hides it. The programmer was making one of two mistakes:
forgetting the required '#include <stdlib.h>', making the compiler
assume that malloc() returns int, or using a C++ compiler which
doesn't allow this particular implicit conversion.
While I admire your sentiment as regards following the C89 Standard, I
still must condemn any compiler that allows the "implict function
declaration" feature, not at least without having to explicitly
request it.

compile a.cpp
--ERROR function declaration missing for "malloc".

compile a.cpp -i_want_implicit_function_declarations
--ERROR Type mismatch, "malloc" returns int.

Martin

Aug 30 '07 #94
Martin Wells <wa****@eircom.netwrites:
Keith Thompson:
>A lot of newbie C programmers will write something like:

int *ptr = malloc(100 * sizeof(int));

and then change it to

int *ptr = (int*)malloc(100 * sizeof(int));

because the compiler warned them about a type mismatch on the
initialization. In fact, the compiler's warning was correct, and the
cast merely hides it. The programmer was making one of two mistakes:
forgetting the required '#include <stdlib.h>', making the compiler
assume that malloc() returns int, or using a C++ compiler which
doesn't allow this particular implicit conversion.

While I admire your sentiment as regards following the C89 Standard, I
still must condemn any compiler that allows the "implict function
declaration" feature, not at least without having to explicitly
request it.

compile a.cpp
--ERROR function declaration missing for "malloc".

compile a.cpp -i_want_implicit_function_declarations
--ERROR Type mismatch, "malloc" returns int.
As do I -- but our condemnation of such compilers doesn't, alas,
prevent newbies from using them.

--
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"
Aug 31 '07 #95

jacob navia 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?

jacob
I assume that you don't want to redefine s as a size_t because it may be
used elsewhere as an int, and you would rather not track down everywhere it
may be used.

So why not replace all the strlen() calls with your own function (maybe
call it i_strlen(), or somesuch name) that returns an int?
--
Bill C.
Aug 31 '07 #96
Bill C:
So why not replace all the strlen() calls with your own function (maybe
call it i_strlen(), or somesuch name) that returns an int?

Not a bad band-aid at all...

...assuming we don't want to actually clean out the wound and
disinfect it.

Really though that's a good idea if "fixing the code" were out of the
question.

Martin

Aug 31 '07 #97
Martin Wells <wa****@eircom.netwrites:
Keith Thompson:
char NumToDigit(unsigned const x)

I assume this was supposed to be 'unsigned int x'.

No, I meant what I wrote. I'm curious as to why you would've thought
that. . ? Anyway, to explain why I wrote it that way:

1: I invariably use "unsigned" as an abbreviation of "unsigned int".
2: I pretty much use const wherever possible.
That was partly a failure on my part to understand what you wrote.
The "unsigned const x" threw me off enough that I momentarily forgot
that "unsigned" is synomymous with "unsigned int". (I probably would
have written "const unsigned int" myself.)

"const" in a parameter declaration doesn't do anything useful for the
caller, since (as I'm sure you know) a function can't modify an
argument anyway. It does prevent the function from (directly)
modifying its own parameter (a local object), but that's of no concern
to the caller.

It would make more sense to be able to specify "const" in the
*definition* of a function but not in the *declaration*. And gcc
seems to allow this:

int foo(int x);

int main(void)
{
return foo(0);
}

int foo(const int x)
{
return x;
}

but I'm not sure whether it's actually legal. In any case, it's not a
style that seems to be common.

I'm sympathetic to the idea uf using const whenever possible.
<OT>If I ever design my own language, declared objects will be
constant (i.e., read-only) by default; if you want to be able to
modify an object, you'll need an extra keyword ('var'?) on the
declaration.</OT>

[...]
With the whole "cast to suppress warning" thing, we're relying more on
industry common practice than anything inherent in the C language or
its standard.

Still though, I advocate its usage.
Fair enough. I don't.

--
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"
Aug 31 '07 #98
Martin Wells wrote:
Keith Thompson:
>I'm not saying that you'd necessarily make this particular mistake.
But adding a cast to silence a warning should be thought of as a
fairly drastic step, and it should be very carefully considered.

I know what you're saying and I agree with you: If you're gonna be
suppressing warnings through the use of casts then you'd better be
certain about what you're doing.

Of course though, in the hands of a competant programmer, the use of
casts to suppress warnings can be quite useful. I've done it quite a
few times, both in C and in C++. Here might be an example in fully
portable code:
If you use casts frequently in C, you are doing something wrong.

If you use naked casts at all in C++, you are doing something very wrong.

In my shops we always have a rule that all casts require a comment, a
good way to make developers think twice before using them.
char NumToDigit(unsigned const x)
{
assert( x >= 0 && x <= 9 ); /* Let's assume that we'll never get
bad input */

return (char)('0' + x); /* No warning, yippee! */
}
I can't fan a compiler that issues a warning without the cast, just out
of interest, which one does?

--
Ian Collins.
Aug 31 '07 #99
Martin Wells <wa****@eircom.netwrites:
While I admire your sentiment as regards following the C89 Standard, I
still must condemn any compiler that allows the "implict function
declaration" feature, not at least without having to explicitly
request it.
Implicit function declarations are part of C89. A compiler that
rejects programs that use this feature is not an implementation
of C89.
--
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_
Aug 31 '07 #100

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by Steffen Fiksdal | last post: by
17 posts views Thread by candy_init | last post: by
5 posts views Thread by edware | last post: by
12 posts views Thread by Alex Vinokur | last post: by
23 posts views Thread by bwaichu | last post: by
318 posts views Thread by jacob navia | last post: by
73 posts views Thread by Yevgen Muntyan | last post: by
89 posts views Thread by Tubular Technician | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by mdpf | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.