size_t problems

[jacob navia]

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

[pete]

Martin Wells wrote:

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

You're right. It should have a cast.

--
pete

[Malcolm McLean]

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:r6************@news.flash-gordon.me.uk...

Malcolm McLean wrote, On 06/09/07 21:03:

>>

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!

Ten thousand pounds, or twenty thousand UD dollars, is by business standards
quite a small amount of money. If you are at all typical your costs are not
in the hardware, which in any case doubles in speed and capacity every
eighteen months or so, but in the software.

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

[Tor Rustad]

CBFalconer wrote:

[...]

>
Why all this fuss constraining a for loop to something unnatural
and confusing. Try the simple straight-forward code:

j = 7;
do {
/* whatever */
++k;
} while (j--);

The original loop I wrote was:

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

so your replacement reads:

j = 7;
do {
if ( (bitmap[i] >j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);
To me, the first option is more readable by far. for(...) loops are
excellent for looping over an index, doing the same with while(..) and
do while(...) loops, gives me headache.

When knowing in advance, how many loops there will be, I "always" use
the for(...) loop.

--
Tor <torust [at] online [dot] no>

[Flash Gordon]

Malcolm McLean wrote, On 07/09/07 21:58:

>
"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:r6************@news.flash-gordon.me.uk...

>Malcolm McLean wrote, On 06/09/07 21:03:

>>>

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!

Ten thousand pounds, or twenty thousand UD dollars, is by business
standards quite a small amount of money.

We are a small company. In any case, why should we bare the costs for
*your* ideas and wants?

If you are at all typical your
costs are not in the hardware,

This year HW is a significant cost, so significant that we are having to
borrow the money to do it.

BTW, I was understating the real costs, those would be much higher since
we have already bought the replacement HW and would have to upgrade it.

which in any case doubles in speed and
capacity every eighteen months or so, but in the software.

The existing HW is failing NOW. If we wait 18 months, or even 6 months,
we could have lost out entire customer base for half of our products.
--
Flash Gordon

[CBFalconer]

Tor Rustad wrote:

>

.... snip ...

>
so your replacement reads:

j = 7;
do {
if ( (bitmap[i] >j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);

To me, the first option is more readable by far. for(...) loops
are excellent for looping over an index, doing the same with
while(..) and do while(...) loops, gives me headache.

Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap[i] >j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

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

[Tor Rustad]

CBFalconer wrote:

Tor Rustad wrote:
... snip ...

>so your replacement reads:

j = 7;
do {
if ( (bitmap[i] >j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);

To me, the first option is more readable by far. for(...) loops
are excellent for looping over an index, doing the same with
while(..) and do while(...) loops, gives me headache.

Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap[i] >j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

Sorry, I don't find your *style* an easy read, we clearly differ in
opinions on this, you might get away with a one-liner, but my basic
point still stands. Even in the above compressed version, I find this
more readable:

for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap[i] >j) & 1;
}

When looping over a known range (j = 7, 6, ... 0), the natural choice is
to use for loops. When not knowing in advance the number of iterations,
that's when while() and do while() loops comes into play.
"To this day, many C programmers believe that 'strong typing' just means
pounding extra hard on the keyboard."
-Peter van der Linden, "Expert C Programming"
So what is "wrong" with:

has_field[k++] = (bitmap[i] >j) & 1;

?

'has_field' has a boolean type, which was typedef'ed elsewhere together
with the TRUE and FALSE macros. So not only have you hard-coded the
values of TRUE and FALSE, but also assume LHS and RHS will have the same
type.
--
Tor <torust [at] online [dot] no>

[CBFalconer]

Tor Rustad wrote:

CBFalconer wrote:

>Tor Rustad wrote:

... snip ...

>>so your replacement reads:

j = 7;
do {
if ( (bitmap[i] >j) & 1 )
{
has_field[k] = TRUE;
}
else
{
has_field[k] = FALSE;
}
++k;
} while (j--);

To me, the first option is more readable by far. for(...) loops
are excellent for looping over an index, doing the same with
while(..) and do while(...) loops, gives me headache.

Note the simplicity of:

j = 7;
do {
has_field[k++] = (bitmap[i] >j) & 1;
} while (j--);

which obviously executes for j = 7, 6, ... 0 and stops.

Sorry, I don't find your *style* an easy read, we clearly differ
in opinions on this, you might get away with a one-liner, but my
basic point still stands. Even in the above compressed version,
I find this more readable:

for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap[i] >j) & 1;
}

That won't work. The original of this was to implement the loop
with unsigned loop variables, so the >= 0 test is always true.

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

[Tor Rustad]

CBFalconer wrote:

Tor Rustad wrote:

[...]

>for(j=7; j>=0; j--)
{
has_field[k++] = (bitmap[i] >j) & 1;
}

That won't work. The original of this was to implement the loop
with unsigned loop variables, so the >= 0 test is always true.

I fixed *my* bug a long time ago, by using

int j;

--
Tor <torust [at] online [dot] no>

[Kelsey Bjarnason]

[snips]

On Fri, 07 Sep 2007 21:58:28 +0100, Malcolm McLean wrote:

"Flash Gordon" <sp**@flash-gordon.me.ukwrote in message
news:r6************@news.flash-gordon.me.uk...

>Malcolm McLean wrote, On 06/09/07 21:03:

>>>

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!

Ten thousand pounds, or twenty thousand UD dollars, is by business standards
quite a small amount of money.

Yet since the cost would be for *no* purpose other than to make *you*
happy, you should be the one to pay it. For every company, every person,
every organization which has to increase their hardware costs just to meet
your weird little preferences.

Going to fork over the dough? No, thought not.

Increased costs where there is a justification for them is generally
acceptable. Making Malcolm happy is not a justification for such costs.

[David Thompson]

On Thu, 30 Aug 2007 18:53:48 -0700, Keith Thompson <ks***@mib.org>
wrote:
<snip>

"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);

<snip>

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.

It is. C99 6.7.5.3p15 not significantly changed from C90 6.5.4.3:
For two function types to be compatible, both shall specify compatible
return types.
Moreover, the parameter type lists, if both are present, shall agree
in the number of
parameters and in use of the ellipsis terminator; corresponding
parameters shall have
compatible types. <snip stuff about oldstyle vs newstyle>
(In the determination of type
compatibility and of a composite type, each parameter declared with
function or array
type is taken as having the adjusted type and each parameter declared
with qualified type
is taken as having the unqualified version of its declared type.)

Thus the definition is compatible with the declaration (and vice
versa), so no constraint is violated, and calls must work. (Assuming
no CV or UB elsewhere, of course.)

OTOH I have encountered a compiler that got this wrong -- IIRC (some
version of) AIX xlc. Plus, it provides IMJ very little benefit.

- formerly david.thompson1 || achar(64) || worldnet.att.net