469,366 Members | 2,251 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,366 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 9583
Chris Torek wrote:
jacob navia <ja***@jacob.remcomp.frwrote:
>Yes, and I have posted that many times. Here is it again:

[some snippage]

Feel free to post that sort of thing in *net* dot lang dot c (but,
please, not *comp* dot lang dot c). :-)

Seriously, the USENET world was rather different in 1982 (as was
the C language, for that matter). On the one hand, you seem to
want change; and yet here, on the other, you want us to pretend it
is still 1982. I find this ... curious.
Yet the list he quoted adequately carries the present thread of
topicality. Repeated below:
>>>It's purpose is to carry on discussion of C programming and
the C programming language. Appropriate topics are

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.
All that is required is a proper definition of C, which is provided
to us by the standard. Note that the standard did not exist in
1982.

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

Sep 4 '07 #351
Malcolm McLean wrote:
"Kelsey Bjarnason" <kb********@gmail.comwrote in message
>Malcolm McLean wrote:
>>"Joe Wright" <jo********@comcast.netwrote in message

I think comp.std.c is the appropriate place to discuss the
future of Standard C.

The campaign for 64 bit ints is a campaign for the future of C,
but it is not a campaign to change the standard.

So how do you ensure C will have 64 bit ints, unless you mandate
this in the standard?

Oh, right, you can't. So it *is* a campaign to change the
standard, to mandate 64-bit ints.

I'm sure all the people using and developing 16-bit, 32-bit and
128-bit implementations will love this idea.

No, it's a campaign for people implementing the standard to make
int 64 bits, where that is the natural integer size suggested by
the architecture. Or in other words, where an arbitrary index
variable needs 64 bits because the architecture supports huge
arrays.

It is not a campaign to change the standard.
Maybe you should notice that, at present, any implementor is
perfectly free to make an int any bit length that equals or exceeds
16. This (surprise) does not exclude 64. Specifying that
"(CHAR_BIT * sizeof int) == 64" would be a (surprise) drastic
change to the standard and would immediately invalidate most
existing implementations and code. The committee (surprise) frowns
on this, as do I.

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

Sep 4 '07 #352
Malcolm McLean wrote:
>
.... snip ...
>
If presented as a portable program that will produce correct
output on any conforming implementation, it is bugged, because an
array of UCHAR_MAX is not guaranteed to fit in available stack
space, sorry, automatic memory. However if you restrict it to 8
bit char platforms, by far the most common, it is OK.
>From which I gather that you wouldn't trust a system with CHAR_BIT
set to 9 or 10?

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

Sep 4 '07 #353
On Thu, 30 Aug 2007 05:29:26 -0400, CBFalconer wrote:
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.
Because an idiot programmer could write unsigned i;
for (i--; i >= 0; i--) and disasters would happen.
(In particular, I did this particular mistake the first time I
ever used a C compiler.)
Of course using while (i--) would do exactly the same, but it also
works with unsigned types.

--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

Sep 4 '07 #354
On Sat, 01 Sep 2007 21:28:59 +0100, Malcolm McLean wrote:
>
"Peter J. Holzer" <hj*********@hjp.atwrote in message
news:sl************************@zeno.hjp.at...
>>
and the admission of long, double, long long or any other type.

Let's face it, admitting types to C was a mistake.
We should go back to B.
The campaign for 64 bit ints wants int to be 64 bits. Then basically it's
ints for everything - no need for unsigned, 63 bits hold a number large
enough to count most things. Other types will be kept for special purposes.
Why should I waste 64 bits to store a flag variable, a value which
can either be a character or EOF, or an enumeration constant, or
the return type of main(), or ...
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

Sep 4 '07 #355
Army:
I fail to see any reason why that 'i' should not be declared as
unsigned. Well, maybe extreme laziness.

Because an idiot programmer could write unsigned i;
for (i--; i >= 0; i--) and disasters would happen.
(In particular, I did this particular mistake the first time I
ever used a C compiler.)
Of course using while (i--) would do exactly the same, but it also
works with unsigned types.

That's still no reason to use signed types when we shouldn't. We don't
accomodate incompetence. Anyway, i >= 0 should yield a warning if i is
unsigned.

Martin

Sep 4 '07 #356
In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrites:
Craig Gullixson wrote:
>In article <46**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrites:
>>Ian Collins wrote:
jacob navia wrote:
int Strlen_i(char *s)
{
char *start=s;
while (*s)
s++;
return s-start;
}
#define strlen Strlen_i;
>
You really should bite the bullet and fix the code.

If aint'broken do not fix it


But it *is* broken as far as the C standard is concerned.

Look, it is not the C standard that runs my code.

It is a mindless processor, churning instruction after instruction, no
mind no standards, no nothing.

I have an aesthetic view of code. What is important in it, from my
viewpoint, is clarity of design and above all, that
IT WORKS.

Code can be written up to the best standards, but if doesn't work or if
it doesn't perform very well I do not care. It is ugly.

The code I am porting is the code of the IDE of lcc-win, and the code of
the debugger. I started writing it around 1992.

The IDE was one of the few pieces of code I salvaged from my failed
lisp interpreter project, that was a technical success but a commercial
failure.

It has been ported to windows 16 bits (from 32 bit DOS emulator with
Delorie), then ported to windows 32 bits in 1996 (windows 95), then
ported to linux 32 bits , under GTK, and then to windows 64 bits.

Believe me, I know what porting means, what is important in code
what is not.
>>
>>There is no simple solution. It means go over the
code and put casts everywhere, fix the new bugs
as you dscover them, etc.

Don't feel like it. There are more interesting things to do.


If one believes in the engineering aspect of software development,
then maintenance is part of the deal. As pointed out elsewhere in
this thread, size_t has been around for 18 years so having to deal
with it should not exactly be a surprise.

Yeah. I have to cope with the possibility of strings larger than 2GB.
Gosh!


You're making not necessarily valid assumptions regarding, int,
size_t, and the maximum size of a string that your application
may want to deal with.

>
>That being said, you are free to either deal with updating your code
or to ignore the compiler warnings. It all depends on how much you
and those others who use the code care about it working correctly and
how difficult it is to port to other compilers, platforms, operating
systems, etc., when needed.

I think that the fix proposed will fit the bill.
>As an example of consequences of not keeping code up to date, I've
spent something in excess of a week getting a network communications
package for a little I/O box embeded in one of our systems to compile
and work correctly after an OS/compiler upgrade of the system needing
to use the I/O box. It turns out that the latest version of the
software package supplied by the vender is *full* of pre C89 crud.

You will agree with me that THAT is much serious than a few compiler
warnings because of size_t I suppose...

I adopted immediately C89 when it come out, because of the prototypes.
It was an INCREDIBLE relaxing thing that I did NOT have to worry
anymore if I always passed the right number of parameters to my
functions. The compiler would yell at me. What a fantastic feeling.
I still remember it!

Let me get this straight - you adopted C89 because of the prototyping,
yet when you started your project in 1992, you didn't bother to use
size_t, included in that same standard, and now you are complaining
about compiler warnings due to not using size_t?

>
>I now have the system working again to the point that it is useful,
however the porting hassles serve as a disincentive for purchasing any
more of the company's products.

Sorry but did you contact the vendor? If they still exists and
sell that package they have surely upgraded it...

Nope. I'm using the latest version of their software, dated August
2005.

---Craig

__________________________________________________ ______________________
Craig A. Gullixson
Instrument Engineer INTERNET: cg********@nso.edu
National Solar Observatory/Sac. Peak PHONE: (505) 434-7065
Sunspot, NM 88349 USA FAX: (505) 434-7029
Sep 4 '07 #357
Army1987 wrote:
On Thu, 30 Aug 2007 05:29:26 -0400, CBFalconer wrote:
>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.
Because an idiot programmer could write unsigned i;
for (i--; i >= 0; i--) and disasters would happen.
Put me in idiot club then. :-( Here, is the code snippet of a bug I
wrote today:

size_t i, j, k;

[...]

for (i=0, k=1; i<iso->field[P1_BITMAPS].length; i++)
{
for (j=7; j>=0; j--,k++)
{
if ( (bitmap[i] >j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}

}
}

now the code has

int i, j, k;

while "iso->field[P1_BITMAPS].length" still has size_t type.

--
Tor <torust [at] online [dot] no>
Sep 4 '07 #358
[snips]

On Tue, 04 Sep 2007 18:57:39 +0200, Richard wrote:
>>>If I were writing such apps, I'd write the body of the code to be as
conforming as possible, meaning it is effectively immune to switching to
a different OS, compiler, or version of a compiler.

What you not uncommonly find is that the actual processing that the app
performs is trivial - maybe it adds a few columns of numbers together and
produces a report.
Who is "we"?
Based on some 20 years' coding and examining the code of others, I'd say
"most programmers".
and the other posters here? There are zillions of C apps, you are
probably using one now, where the processing is indeed trivial compared
to wait time.
Where did wait time come into the question? The discussion was about
processing done by the app, as contrasted to the UI for the app - not a
thing about wait times. Sorry, did I miss that in Malcolm's comments?
Sep 4 '07 #359
jacob navia wrote, On 04/09/07 19:54:

<snip>
The problem with comp.std.c is that many people there are the same
"regulars" here, so I do not see much difference actually.
If there is not much difference then why not at least remove one reason
for people to complain against you by posting suggestions for changes to
C there instead of here.
--
Flash Gordon
Sep 4 '07 #360

"Kelsey Bjarnason" <kb********@gmail.comwrote in message
news:hl************@spanky.localhost.net...
[snips]
Where did wait time come into the question? The discussion was about
processing done by the app, as contrasted to the UI for the app - not a
thing about wait times. Sorry, did I miss that in Malcolm's comments?
That's a slightly different issue. Run time is not unrelated to the
complexity of the code doing the processing, but it is not the same thing at
all. Code can be very hard to write yet execute in under just noticeable
time. Alternatively it can be very simple but soak up as much processing
power as you can throw at it.

However the majority of desktop apps do fairly trivial processing in both
senses. The functions are not mathematically complicated in any way, and
they don't take much time to execute. When I say "the majority" obviously
there are exceptions. A chess program that would beat Kasparov is one of
them.

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

Sep 4 '07 #361

"CBFalconer" <cb********@yahoo.comwrote in message
news:46***************@yahoo.com...
Malcolm McLean wrote:
>>
... snip ...
>>
If presented as a portable program that will produce correct
output on any conforming implementation, it is bugged, because an
array of UCHAR_MAX is not guaranteed to fit in available stack
space, sorry, automatic memory. However if you restrict it to 8
bit char platforms, by far the most common, it is OK.
>>From which I gather that you wouldn't trust a system with CHAR_BIT
set to 9 or 10?
You're allowed 32 767 bytes in automatic memory, minimum. However if the
compiler writer has misread the campaign for 64 bit ints as the "campaign
for 64 byte ints", which is possible, even 9 bits will break.

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

Sep 4 '07 #362

"Ian Collins" <ia******@hotmail.comwrote in message
news:5k************@mid.individual.net...
Malcolm McLean wrote:
>No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the
architecture. Or in other words, where an arbitrary index variable needs
64 bits because the architecture supports huge arrays.
The "natural size" for int on most common 64 bit systems is 32 bits.
Unless you pick a specific definition of "natural" that excludes code
size and performance.
"natural" is the size needed for an arbitrary array index, because that is
what ints are mainly used for.

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

Sep 4 '07 #363

"Army1987" <ar******@NOSPAM.itwrote in message
news:pa****************************@NOSPAM.it...
On Sat, 01 Sep 2007 21:28:59 +0100, Malcolm McLean wrote:
>>
"Peter J. Holzer" <hj*********@hjp.atwrote in message
news:sl************************@zeno.hjp.at...
>>>
and the admission of long, double, long long or any other type.

Let's face it, admitting types to C was a mistake.
We should go back to B.
The campaign for 64 bit ints wants int to be 64 bits. Then basically it's
ints for everything - no need for unsigned, 63 bits hold a number large
enough to count most things. Other types will be kept for special
purposes.

Why should I waste 64 bits to store a flag variable, a value which
can either be a character or EOF, or an enumeration constant, or
the return type of main(), or ...
The standards benefit. If every nut fits every bolt, productivity is
massively increased. Of course every individual engineer would rather have
nuts and bolts of the particular size that suit the problem he is working
on, oh and the optimal thread pitch as well. The benefits only come when
almost everyone is using the same nut and the same bolt, and they are much
greater than most people would imagine from intuition.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Sep 4 '07 #364
Malcolm McLean wrote:
>
"Ian Collins" <ia******@hotmail.comwrote in message
news:5k************@mid.individual.net...
>Malcolm McLean wrote:
>>No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the
architecture. Or in other words, where an arbitrary index variable needs
64 bits because the architecture supports huge arrays.
The "natural size" for int on most common 64 bit systems is 32 bits.
Unless you pick a specific definition of "natural" that excludes code
size and performance.
"natural" is the size needed for an arbitrary array index, because that
is what ints are mainly used for.
Not in my world.

--
Ian Collins.
Sep 4 '07 #365
On Mon, 03 Sep 2007 19:32:47 +0200, jacob navia wrote:
Ed Jensen wrote:
>pete <pf*****@mindspring.comwrote:
>>comp.std.c is for discussing the future of C.

Where can one find the original charters for both comp.lang.c and
comp.std.c?

Here it is:
Hmm. An article which is not a charter - snipped.

Sorry, you said you were going to post the charter, which doesn't exist,
for the group; could you do so now?
Sep 4 '07 #366
[snips]

On Tue, 04 Sep 2007 20:54:34 +0200, jacob navia wrote:
Mostly, that group has no developers, just language lawyers, people
that write compilers
Ah, so people who write compilers aren't developers, they're... plumbers?
Sep 4 '07 #367
Malcolm McLean wrote, On 04/09/07 21:44:
>
"Army1987" <ar******@NOSPAM.itwrote in message
news:pa****************************@NOSPAM.it...
>On Sat, 01 Sep 2007 21:28:59 +0100, Malcolm McLean wrote:
>>>
"Peter J. Holzer" <hj*********@hjp.atwrote in message
news:sl************************@zeno.hjp.at...

and the admission of long, double, long long or any other type.

Let's face it, admitting types to C was a mistake.
We should go back to B.

The campaign for 64 bit ints wants int to be 64 bits. Then basically
it's
ints for everything - no need for unsigned, 63 bits hold a number large
enough to count most things. Other types will be kept for special
purposes.

Why should I waste 64 bits to store a flag variable, a value which
can either be a character or EOF, or an enumeration constant, or
the return type of main(), or ...
The standards benefit. If every nut fits every bolt, productivity is
massively increased. Of course every individual engineer would rather
have nuts and bolts of the particular size that suit the problem he is
working on, oh and the optimal thread pitch as well. The benefits only
come when almost everyone is using the same nut and the same bolt, and
they are much greater than most people would imagine from intuition.
As previously pointed out to you and ignored on several occasions, nuts
and bolts come in LOTS of different sizes. The nuts and bolts used to
hold the engine in your car would not fit in my PDA, the nuts and bolts
in my PDA would not be able to hold your cars engine in place.
--
Flash Gordon
Sep 4 '07 #368
Malcolm McLean wrote, On 04/09/07 21:39:
>
"Ian Collins" <ia******@hotmail.comwrote in message
news:5k************@mid.individual.net...
>Malcolm McLean wrote:
>>No, it's a campaign for people implementing the standard to make int 64
bits, where that is the natural integer size suggested by the
architecture. Or in other words, where an arbitrary index variable needs
64 bits because the architecture supports huge arrays.
The "natural size" for int on most common 64 bit systems is 32 bits.
Unless you pick a specific definition of "natural" that excludes code
size and performance.
"natural" is the size needed for an arbitrary array index,
No, or we would have had lots of compilers for 16 bit processors with
between 20 and 32 bit ints. Highly inefficient.
because that
is what ints are mainly used for.
Something you keep asserting even though everyone else who expresses an
opinion disagrees and without suitable evidence to back up you claim.
Repeatedly asserting what people believe to be a fallacy and using it as
an argument for doing something that people believe is the wrong thing
to do is unlikely to bring anyone round to your way of thinking.
--
Flash Gordon
Sep 4 '07 #369
Kelsey Bjarnason wrote:
[snips]

On Tue, 04 Sep 2007 20:54:34 +0200, jacob navia wrote:
>Mostly, that group has no developers, just language lawyers, people
that write compilers

Ah, so people who write compilers aren't developers, they're... plumbers?
But not!

I am not AGAINST them but I think language discussion should be done
with the developers, not specially with language lawyers and
specialists. Even if they are needed of course.
Sep 4 '07 #370
Tor:
now the code has

int i, j, k;

You'd many other options. Here's just two:

Option A:

for (j = 7+1; j--; ++k)

Option B:

for (j = 7; j != -1; --j,++k)

Martin

Sep 4 '07 #371
Martin Wells wrote:
Tor:
>now the code has

int i, j, k;


You'd many other options. Here's just two:

Option A:

for (j = 7+1; j--; ++k)

Option B:

for (j = 7; j != -1; --j,++k)

Martin
But that is not the point. The point is that you have to take care of
this stuff you see?

Many people (me included) would rather NOT TAKE CARE OF THIS STUFF!
Sep 4 '07 #372
jacob:
But that is not the point. The point is that you have to take care of
this stuff you see?

Many people (me included) would rather NOT TAKE CARE OF THIS STUFF
Fair enough. Then all you need is a signed integer type whose positive
range is at least that of "size_t". I suppose the Standard could have
provided such a type, but it would probably be horribly inefficient
as, on a lot of systems in anyway, it would entail tagging a byte onto
the end of a size_t. For instance, let's say that size_t is 64-Bit on
a particular system, and that the max register size on this system is
64-Bit. Well we'll need 65 bits if we want a signed type, but this
will have to be implemented under-the-hood as a 64-Bit value
accompanied by a byte to say whether its positive or negative.

The other option was to allow the competent programmer to solve his
problem.

If you're guaranteed to be working with sizes smaller than 32767, then
by all means use int. You might want to you casts in places though if
you're to suppress compiler warnings.

Martin

Sep 4 '07 #373
On Sun, 02 Sep 2007 20:35:47 +0100, Malcolm McLean wrote:
"Martin Wells" <wa****@eircom.netwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...
>Malcolm:
>>What are those ints going to be used for? We don't know, but such a
useful
function would surely find a place in calculating array indices, or
intermediate values, such as counts, to calculating array indices.

So we need another version

void AddFiveToEachElementsz(size_t *p, size_t len)

The fuse has gone off. That's what the admission of size_t does to your
code.


Sorry I haven't a clue what you're talking about. Could you please
explain more clearly?
Yes.
It the standards problem. As long as every nut will fit every bolt,
everything is simple. Engineer one says "give me a nut", engineer two
supplies it.
I'm building a watch, the guy next to me is building a 75,000 HP diesel
engine. We share a bin of bolts (and nuts), because bolts (and nuts) are
now standardized, so if I need a bolt - say to clamp down the back of the
movement housing - I reach in and grab one, and when I'm done my watch
weighs 1200 pounds and measures four feet in its smallest dimension.

Yup, sounds good. Every nut fits every bolt, everything is simple.
--
I believe that baptism is a good thing,
with a little soap. -- Robert Curry
Sep 4 '07 #374
On Tue, 04 Sep 2007 20:54:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>
Mostly, that group has no developers, just language lawyers, people
that write compilers, etc, and have very specific questions about
paragraph xxx of the standard ...
....
>The problem with comp.std.c is that many people there are the same
"regulars" here, so I do not see much difference actually.
....

These two facts cannot both be true, since they're contradictory.
>Some discussions are possible. For instance when Mr Heathfield mentioned
in one of those discussions that he missed operator overloading I tried
to argument my position and sent a lengthy message explaining why
this would improve C.

The answer was a boatload of insults from Mr Heathfield
post a reference to the "boatload of insults" which were posted in
comp.std.c
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Sep 4 '07 #375
Martin Wells wrote:
Tor:
>now the code has

int i, j, k;


You'd many other options. Here's just two:

Option A:

for (j = 7+1; j--; ++k)

Option B:

for (j = 7; j != -1; --j,++k)
When the location of the bug was detected, fixing it wasn't a challenge,
but I wanted a max *readable* solution. Your options, are less readable
IMO. Introducing a signed/unsigned mismatch was no big deal here, the
unsigned value was known to be in the range 0 < x < 129.

--
Tor <torust [at] online [dot] no>
Sep 5 '07 #376
jacob navia wrote:
Martin Wells wrote:
>Tor:
>>now the code has

int i, j, k;


You'd many other options. Here's just two:

Option A:

for (j = 7+1; j--; ++k)

Option B:

for (j = 7; j != -1; --j,++k)

Martin

But that is not the point. The point is that you have to take care of
this stuff you see?

Many people (me included) would rather NOT TAKE CARE OF THIS STUFF!
AFAIK, it is the first time I have written j >= 0 for an unsigned, so
this is not a frequent case, and will not stop me from using size_t in
the future.

However, it would have been nice if the *compiler* had warned me about
the bug. Does your compiler give a warning in this case? If not, why not
add it?

--
Tor <torust [at] online [dot] no>
Sep 5 '07 #377
Your options, are less readable IMO.
Yes, I agree that they are.

Introducing a signed/unsigned mismatch was no big deal here, the
unsigned value was known to be in the range 0 < x < 129.

Then your int solution is actually quite good.

What I'm against however, is the use of inappropriate types all the
time even when the max number is not known.

Also, if you're going to be converting from larger integer types to
smaller ones, then I'd advocate using a cast to suppress a compiler
warning so you don't end up with the mess that jacob had. It wouldn't
be a bad idea to do stuff like:

#define i_strlen(x) ( (int)strlen((x)) )

Martin

Sep 5 '07 #378
However, it would have been nice if the *compiler* had warned me about
the bug. Does your compiler give a warning in this case? If not, why not
add it?

I've seen a lot of compilers warn about redundant expressions and
statments, reason being that if an expression or statement is
redundant then the programmer probably intended for it to be or mean
something else. It would warn about the following for instance:

int main(void)
{
int x = 7;

x + 4; /* Warning: Redundant statement */
}

Martin

Sep 5 '07 #379
Malcolm McLean wrote:
"CBFalconer" <cb********@yahoo.comwrote in message
>Malcolm McLean wrote:
>>>
... snip ...
>>>
If presented as a portable program that will produce correct
output on any conforming implementation, it is bugged, because an
array of UCHAR_MAX is not guaranteed to fit in available stack
space, sorry, automatic memory. However if you restrict it to 8
bit char platforms, by far the most common, it is OK.

From which I gather that you wouldn't trust a system with CHAR_BIT
set to 9 or 10?

You're allowed 32 767 bytes in automatic memory, minimum. However
if the compiler writer has misread the campaign for 64 bit ints as
the "campaign for 64 byte ints", which is possible, even 9 bits
will break.
Where did you get that weird idea? Maybe you should look up the
meaning of CHAR_BIT.

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

Sep 5 '07 #380
Flash Gordon wrote:
>
.... snip ...
>
As previously pointed out to you and ignored on several occasions,
nuts and bolts come in LOTS of different sizes. The nuts and bolts
used to hold the engine in your car would not fit in my PDA, the
nuts and bolts in my PDA would not be able to hold your cars
engine in place.
The proposed ISO standard sets all bolt sizes to be 1/4" x 2-56.
:-)

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

Sep 5 '07 #381
Tor Rustad wrote:
>
.... snip ...
>
Put me in idiot club then. :-( Here, is the code snippet of a bug I
wrote today:

size_t i, j, k;

[...]

for (i=0, k=1; i<iso->field[P1_BITMAPS].length; i++) {
for (j=7; j>=0; j--,k++) {
j = 7;
do {
....
k++;
} while (0 != j--);

--
"To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is
not only unpatriotic and servile, but is morally treasonable
to the American public." -- Theodore Roosevelt
--
Posted via a free Usenet account from http://www.teranews.com

Sep 5 '07 #382
On 2007-09-04 23:33, CBFalconer <cb********@yahoo.comwrote:
Malcolm McLean wrote:
>"CBFalconer" <cb********@yahoo.comwrote in message
>>Malcolm McLean wrote:
If presented as a portable program that will produce correct
output on any conforming implementation, it is bugged, because an
array of UCHAR_MAX is not guaranteed to fit in available stack
space, sorry, automatic memory. However if you restrict it to 8
bit char platforms, by far the most common, it is OK.

From which I gather that you wouldn't trust a system with CHAR_BIT
set to 9 or 10?

You're allowed 32 767 bytes in automatic memory, minimum. However
if the compiler writer has misread the campaign for 64 bit ints as
the "campaign for 64 byte ints", which is possible, even 9 bits
will break.

Where did you get that weird idea? Maybe you should look up the
meaning of CHAR_BIT.
I haven't seen the program you are discussing here, but from the
description I guess that it contains an automatic variable like

int foo[UCHAR_MAX+1];

If there is a compiler where sizeof int is 64 (64 *byte* int, not 64
*bit* int) and UCHAR_MAX is 511 (CHAR_BIT == 9), then sizeof foo is 64 *
512 == 32768: On byte larger than guarantueed by the standard, so this
may indeed fail (of course an implementor which uses 576 bit ints on a
machine with so little memory that it can't create a 32kB array would be
seriously wacky).

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"
Sep 5 '07 #383
On 2007-09-04 22:17, Martin Wells <wa****@eircom.netwrote:
Tor:
>now the code has

int i, j, k;
[originally it was: size_t i, j, k;]
>
You'd many other options. Here's just two:
[...]
Option B:

for (j = 7; j != -1; --j,++k)
This isn't completely portable. If size_t is smaller than int, j will
wrap around to a positive value != -1. You would have to write:

for (j = 7; j != (size_t)-1; --j,++k)

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"
Sep 5 '07 #384
On 2007-09-04 22:32, Martin Wells <wa****@eircom.netwrote:
jacob:
>Many people (me included) would rather NOT TAKE CARE OF THIS STUFF
If you want Perl, you know where to find it.

Fair enough. Then all you need is a signed integer type whose positive
range is at least that of "size_t". I suppose the Standard could have
provided such a type, but it would probably be horribly inefficient
as, on a lot of systems in anyway, it would entail tagging a byte onto
the end of a size_t.
[...]
The other option was to allow the competent programmer to solve his
problem.
The third option is to restrict the object size to half the
theoretically possible value, i.e. 32767 bytes with 16 bit size_t,
2147483647 with 32 bit size_t and 9223372036854775807 bytes with 64 bit
size_t. No problem for 64 bit systems and not an undue restriction on
most 32 bit systems: Many reserve a rather large part of the address
space or have an unfortunate memory layout, so that you can't get a
single object larger than about 2 GB anyway (and if your problem needs
more than 2 GB today, it probably will need more than 4 GB next year, so
you'd better start planning for that). The real problems were probably
(especially in the late 1980's when the standard was written) with 16
bit systems. Reducing the maximum possible size from 64 kB to 32 kB
would probably have hurt quite a few programs.

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"
Sep 5 '07 #385
Peter:
for (j = 7; j != -1; --j,++k)

This isn't completely portable. If size_t is smaller than int, j will
wrap around to a positive value != -1. You would have to write:

for (j = 7; j != (size_t)-1; --j,++k)

In writing the code, I thought it so strange for size_t to be anything
smaller than an "unsigned int" that I didn't make allowances for it
being any smaller.

Are you certain that size_t can be smaller than an unsigned int? If
so, that's a little strange.

As an aside, I had originally written it with the cast so that it
would work with any unsigned integer type, but changed it because I
knew I'd have a 20-minute-long discussin afterward with the people who
have phobias of casts, much less redundant casts.

Martin

Sep 5 '07 #386
Keith Thompson <ks***@mib.orgwrote:
>Mostly, that group has no developers, just language lawyers, people
that write compilers, etc, and have very specific questions about
paragraph xxx of the standard ...

And that's your *new* reason for not posting to comp.std.c, but you
don't acknowledge that your previous reason was invalid.
Jacob's "excuses" for not posting to comp.std.c isn't any worse than
some other people's "excuses" for not posting to comp.lang.c.moderated.
Sep 5 '07 #387
I posted the specifications of operator overloading to
comp.std.c

Now, please go there and let's discuss the TECHNICAL issues and stop the
polemic

OK?
Sep 5 '07 #388
[snips]

On Wed, 05 Sep 2007 14:49:11 +0200, Peter J. Holzer wrote:
If there is a compiler where sizeof int is 64 (64 *byte* int, not 64
*bit* int) and UCHAR_MAX is 511 (CHAR_BIT == 9), then sizeof foo is 64 *
512 == 32768: On byte larger than guarantueed by the standard, so this
may indeed fail (of course an implementor which uses 576 bit ints on a
machine with so little memory that it can't create a 32kB array would be
seriously wacky).
Ds9k invoked in terminally perverse mode?

--
Not hungry, not homeless. Will work for sex.
Sep 5 '07 #389
jacob navia wrote, On 05/09/07 17:48:
I posted the specifications of operator overloading to
comp.std.c

Now, please go there and let's discuss the TECHNICAL issues and stop the
polemic

OK?
Fine with me. Although the middle of this thread was probably not the
best place to announce that you have done this.
--
Flash Gordon
Sep 5 '07 #390
I cannot find any requirement in the standard regarding the minimum size
of size_t. It is simply an "unsigned integer type".

Usually I'm a stickler for portability, but in this case I think I
jumped the gun with my assumptions about size_t. If the Standard
doesn't make any guarantees/restrictions then I suppose we're left
with some_size_t_variable != (size_t)-1.

Martin

Sep 5 '07 #391
Martin Wells <wa****@eircom.netwrites:
>I cannot find any requirement in the standard regarding the minimum size
of size_t. It is simply an "unsigned integer type".

Usually I'm a stickler for portability, but in this case I think I
jumped the gun with my assumptions about size_t. If the Standard
doesn't make any guarantees/restrictions then I suppose we're left
with some_size_t_variable != (size_t)-1.
I'd use SIZE_MAX, to make the code unarguably correct and easier
to read at the same time. If you don't have <stdint.h>, you can
always just "#define SIZE_MAX ((size_t) -1)" yourself.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,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;}}}
Sep 5 '07 #392
On 3 Sep 2007 at 14:12, jacob navia wrote:
Chris Dollin wrote:
>Martin Wells wrote:
>>If a machine is 32-bit, shouldn't it access a 32-bit number quicker
than an 8-bit number?

That depends on the machine.

No-one really cares, anyway, not about /a/ 32-bit number. In the case
of Jacob's 20 million people, the question should be whether it's
faster to access 20 million ints or twenty million bytes -- at which
point, such atopical things as caches (presence and size of) and
disc speed (data for the loading of) may matter more than how long
it takes for the machine to mask out the upper 24 bits of a value.

In all cases, caches or not, i/o of 20MB is faster than i/o of 80MB.

It *could* be that disk caches go to 80MB and then it would be the same.
Not with main memory though. Main memory caches go into the MB range at
most, and L1 caches are even smaller.

Besides there are other effects to take into consideration.
Normally, machines load data from memory into a cache line
of 32 or 64 bytes, i.e. you read 32 bytes at a time.

Using sparingly memory, for instance making
your structure fit into 32 bytes, will make it load in a single
read operation into the L1 cache. Bigger structures take MUCH more
time since 2 or more reads are necessary...
You have no clue what you are talking about... there are many other
considerations than the size in bytes of a struct when you're thinking
at the level of hitting or missing cache.
The general point I want to make is that we have to use the correct type
for the data and situation we are working with.

It would be a bad situation where we would have just
"int with 64 bits"
and we would use int for characters, shorts, etc etc, wasting
an enormous space for nothing at each structure we would use.
This sort of absolute statement is complete balderdash. Once again you
completely fail to understand the complex interaction of various
tradeoffs in a modern system.
True, everything would be much simpler (this is the reason why
Malcolm advocates this I think), but the lost of flexibility would
be enormous.

Besides, in small machines, C would not even run: it wouldn't have
enough RAM to load the program!
A C program runs quite happily in my toaster. What do you mean by a
"small machine"?

Sep 5 '07 #393

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46**********************@news.orange.fr...
>A N Other wrote:
When we are speaking of cache, the size *is* a fundamental
parameter. If my structure makes 1MB it will not fit in the
cache sorry. And yes, there are many OTHER considerations,
like way of accessing structures in an array, locality
and many others, but size is surely an important one!
I am prepared to accept that cache usage would be improved with smaller
integers. However size_t has to be 64 bits anyway, and size_t is such a
common type, if code is written properly, that the savings from having 64
bit ints would be quite small.

However the problem we face isn't usually that code executes too slowly. It
is that units of code don't talk to each other properly. That's why most
projects go over budget, or don't get completed at all.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Sep 6 '07 #394
On Wed, 05 Sep 2007 15:13:32 +0200, Peter J. Holzer wrote:
The third option is to restrict the object size to half the
theoretically possible value, i.e. 32767 bytes with 16 bit size_t,
2147483647 with 32 bit size_t and 9223372036854775807 bytes with 64 bit
size_t.
In a defect report, it was suggested to either require size_t to
be large enough to be able to contain the size of any supported
object, or to specify what happens if sizeof is applied on an
object larger than SIZE_MAX bytes, or to explicitly state that the
behavior is undefined in such a case. The committee's answer was
more-or-less "any program using any object larger than 64KB is not
strictly conforming anyway, so we don't give a damn".

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes” feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

Sep 6 '07 #395
Army1987 <ar******@NOSPAM.itwrites:
[...]
I was remembering that the standard forbid size_t to have a lower
integer conversion rank than int, but probably I just dreamt of
it, since I can't find it anymore anywhere.
N1124 recommends (but doesn't require) that size_t and ptrdiff_t
shouldn't have an integer conversion rank greater than that of signed
long. (C99 didn't have this wording; it was added by one of the TCs.)
Perhaps that's what you were thinking of?

--
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"
Sep 6 '07 #396
Malcolm McLean wrote, On 06/09/07 21:03:
>
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:46**********************@news.orange.fr...
>A N Other wrote:
When we are speaking of cache, the size *is* a fundamental
parameter. If my structure makes 1MB it will not fit in the
cache sorry. And yes, there are many OTHER considerations,
like way of accessing structures in an array, locality
and many others, but size is surely an important one!
I am prepared to accept that cache usage would be improved with smaller
integers.
Good.
However size_t has to be 64 bits anyway, and size_t is such a
common type, if code is written properly, that the savings from having
64 bit ints would be quite small.
Maybe in your applications, but as has been pointed out that does not
apply to vast number of applications.
However the problem we face isn't usually that code executes too slowly.
You might not, but I have to deal with hundreds of users on a single
server and vast amounts of data. Just like lots of other people.
It is that units of code don't talk to each other properly.
It may cause you problems, I find it very easy both with my own SW and
3rd party SW I link to or otherwise communicate with.
That's why
most projects go over budget, or don't get completed at all.
It has *never* stopped any project I have been involved with, and has
always had a far smaller impact than changing or poorly specified
requirements.

Now, seeing as conservatively your proposal will increase my companies
storage requirements by 10% (it is probably a lot more) and that could
easily increase our storage costs (we are replacing kit currently) by
5%, that will be another 3500UKP. Then if it ups the cost of RAM
required by servers by 50UKP, and we have to go to the next processor up
costing another 100UKP (we are already getting high end processors), for
our 10 servers that is another 5000UKP. Will you give us that 5000UKP to
cover the increased costs you want to force on us? We are only a small
company, our customers will find there costs increased by rather more.
That is assuming your are write that it will have only a small impact on
performance, if everyone else is write you will have to give us a lot
more money!
--
Flash Gordon
Sep 6 '07 #397
Army:
SIZE_MAX is guaranteed to be at least 0xFFFF.
So that means size_t must have at least 16 value representation bits.
But then you could have a machine with 32-bit unsigned int's, and
something like:

typedef short unsigned size_t;

, which still makes our "!= -1" code buggy.

Martin

Sep 6 '07 #398
Army1987 wrote:
On Wed, 05 Sep 2007 15:13:32 +0200, Peter J. Holzer wrote:
>The third option is to restrict the object size to half the
theoretically possible value, i.e. 32767 bytes with 16 bit
size_t, 2147483647 with 32 bit size_t and 9223372036854775807
bytes with 64 bit size_t.

In a defect report, it was suggested to either require size_t to
be large enough to be able to contain the size of any supported
object, or to specify what happens if sizeof is applied on an
object larger than SIZE_MAX bytes, or to explicitly state that
the behavior is undefined in such a case. The committee's answer
was more-or-less "any program using any object larger than 64KB
is not strictly conforming anyway, so we don't give a damn".
Where did you drag this bit of foolishness from? Pure nonsense,
obviously so since the purpose of size_t is to handle ANY existing
object size.

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

Sep 7 '07 #399
CBFalconer <cb********@yahoo.comwrites:
Army1987 wrote:
>On Wed, 05 Sep 2007 15:13:32 +0200, Peter J. Holzer wrote:
>>The third option is to restrict the object size to half the
theoretically possible value, i.e. 32767 bytes with 16 bit
size_t, 2147483647 with 32 bit size_t and 9223372036854775807
bytes with 64 bit size_t.

In a defect report, it was suggested to either require size_t to
be large enough to be able to contain the size of any supported
object, or to specify what happens if sizeof is applied on an
object larger than SIZE_MAX bytes, or to explicitly state that
the behavior is undefined in such a case. The committee's answer
was more-or-less "any program using any object larger than 64KB
is not strictly conforming anyway, so we don't give a damn".

Where did you drag this bit of foolishness from? Pure nonsense,
obviously so since the purpose of size_t is to handle ANY existing
object size.
It may be the intent that size_t can hold the size of any object, but
it doesn't quite say so; what it says is that size_t is "the unsigned
integer type of the result of the sizeof operator" (C99 7.17p2).

One issue that was discussed at length a while ago (and I don't
propose to reopen it) is that calloc() could conceivably allow the
creation of an object bigger than SIZE_MAX bytes (though an
implementation can avoid that issue by rejecting any such request).

Another possible issue:

char really_big[SIZE_MAX][2];
sizeof really_big;

Certainly an implementation may reject the declaration of
'really_big', but must it do so? If the declaration is accepted I
believe that evaluating 'sizeof really_big' invokes undefined
behavior. What about a program that declares 'really_big' but never
applies 'sizeof' to it?

--
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"
Sep 7 '07 #400

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
reply views Thread by zhoujie | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.