size_t problems

[Martin Wells]

Re: size_t problems


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

[Charlton Wilbur]

Re: size_t problems

>>>>"BP" == Ben Pfaff <blp@cs.stanfor d.eduwrites:

BPEd Jensen <ejensen@visi.c omwrites:

> 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
cwilbur@chromat ico.net

[Martin Wells]

Re: size_t problems


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(unsi gned 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

[Martin Wells]

Re: size_t problems

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(10 0 * 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_decla rations
--ERROR Type mismatch, "malloc" returns int.

Martin

[Keith Thompson]

Re: size_t problems

Martin Wells <warint@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(10 0 * 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_decla rations
--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_Keit h) kst-u@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"

[spacecriter \(Bill C\)]

Re: size_t problems


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.999999999999 9999999999999%
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.

[Martin Wells]

Re: size_t problems

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

[Keith Thompson]

Re: size_t problems

Martin Wells <warint@eircom. netwrites:

Keith Thompson:

char NumToDigit(unsi gned 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_Keit h) kst-u@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"

[Ian Collins]

Re: size_t problems

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(unsi gned 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.

[Ben Pfaff]

Re: size_t problems

Martin Wells <warint@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_

[CBFalconer]

Re: size_t problems

Keith Thompson 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 does if you are passing a pointer to a const item. That way you
can protect the parameter and avoid copying large objects. Such
as, but not limited to, strings.

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

[Ian Collins]

Re: size_t problems

CBFalconer wrote:

Keith Thompson 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 does if you are passing a pointer to a const item. That way you
can protect the parameter and avoid copying large objects. Such
as, but not limited to, strings.
>

Why would you want to? That implies writing something like

void f( const int* const );

which is rather pointless.

simply writing

void f( const int* );

protects the pointed to item. You can change the value of the pointer,
but it still points to constant data.

I'm not sure where "avoid copying large objects" comes form, care to
elaborate?

--
Ian Collins.

[Richard Bos]

Re: size_t problems

Ben Bacarisse <ben.usenet@bsb .me.ukwrote:

gazelle@xmissio n.xmission.com (Kenny McCormack) writes:
>

both of you just post carp

>
Fishing for compliments?

No, Kenny's just trolling again.

Richard

[Richard]

Re: size_t problems

rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:

Ben Bacarisse <ben.usenet@bsb .me.ukwrote:
>

>gazelle@xmissio n.xmission.com (Kenny McCormack) writes:
>>

both of you just post carp

>>
>Fishing for compliments?

>
No, Kenny's just trolling again.
>
Richard

I thing someone missed the joke.

[Malcolm McLean]

Re: size_t problems


"Ben Pfaff" <blp@cs.stanfor d.eduwrote in message
news:87sl61yrvs .fsf@blp.benpfa ff.org...

"Malcolm McLean" <regniztar@btin ternet.comwrite s:
>

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

If you are indexing an arbitrary-length array, effectively now it is an
error to use int. That's a big change from what most people would recognise
as "C". It is also very undesireable that i, which holds the index, is
described as a "size_t" when it certainly doesn't hold a size. N, the count,
doesn't hold an amount of memory either, but is also a size_t.

Thnen you've got the problem of two standards, in fact 14 standards at last
count, for holding integers. That makes it harder and harder to make
functions fit together. Code is littered with casts because cursorxy takes
two int *s, whilst drawxy takes two size_ts.

The best solution is to to say "int is a type which can index any array"
which means that int must have the same number of bits as a char pointer,
which on 99% of platforms is no problem at all. By making the standard
slightly loose the wierdos can break this rule - if char *'s have an extra
four bits, because underlying bytes are 32 bits, it might be unacceptably
inefficient to have ints large enough to hold them, but the loss of the
ability to index strings taking up an eighth of the address space or more,
without special code, isn't too bad a loss, and the problem won't be solved
by size_t.

There is also the issue of signedness. Again, this is more theoretical than
practical. In practise you can live without the extra bit, because it only a
problem handling

The other problem is backwards compatibility with legacy libraries. However,
as I pointed out, 64 bits of memory will be the maximum for a long time to
come. We mustn't damage C now purely to call a few APIs left over from
32-bit days.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm