size_t, when to use it? (learning)

[Kaz Kylheku]

[email protected] wrote:

(snip)



Yes if you sizeof(type) someone could change the type, such that
it didn't match.

But one could also change the name such that it didn't match.

In the expression sizeof(X) or sizeof X, the compiler doesn't verify
that X agrees with anything in the surrounding code semantically;
the sizeof expression stands completely alone.

Now in sizeof(X), where X is an identifier, X could contain a typo such
that it happens to match a declared identifier. Since the parentheses are
present, this wrong X can be a typedef name or an object.

If X has a typo in sizeof X, X can only be an object, not a type; there is a
smaller "typo target space". There are usually fewer declared objects than
there are declared type names and objects.

If sizeof *X has a typo in identifier X, the typo has to land on an
identifier which is declared such that it takes a unary * operator.
There are usually fewer declared pointers than there are declared objects.

 

[Ian Collins]

[email protected] wrote:

(snip)



Yes if you sizeof(type) someone could change the type, such that
it didn't match.

But one could also change the name such that it didn't match.

There might have been:

short *a;
(... some lines in between)
a=malloc(100*sizeof(*a));

and someone later changes it to:

short *a;
long *b;
(... some lines in between)
b=malloc(100*sizeof(*a));

The "some lines in between" is one reason for preferring sizeof object,
especially for a reviewer of the code.

 

[Keith Thompson]

[email protected] wrote:

(snip)

I've fixed several bugs in my career where people used `sizeof (type)',
where type was wrong. I've yet to encounter a similar bug where
people used `sizeof object'. Anecdotal, but the fact of the
matter is that `sizeof object' states more precisely what you
want, and precision is important when programming.

[...]

Yes if you sizeof(type) someone could change the type, such that
it didn't match.

But one could also change the name such that it didn't match.

There might have been:

short *a;
(... some lines in between)
a=malloc(100*sizeof(*a));

and someone later changes it to:

short *a;
long *b;
(... some lines in between)
b=malloc(100*sizeof(*a));

Now, note that sizeof(*a) doesn't eliminate the possibility
of bugs, but changes the ones that are possible.

I can't tell which one a given person is more or less likely
to do.

If you write

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

where b is of type long*, the error isn't obvious when you look at that
line. You have to track down the declaration of b to make sure that its
declared type is consistent with the argument to sizeof. And in more
complex cases (such as "sizeof (int*)" vs. "sizeof (int**)"), it can
still take a moment to parse the declaration and determine just what the
type is.

None of this is horribly difficult, and smart editors and IDEs can make
it easier. But if you write:

b = malloc(100 * sizeof *a);

the inconsistency is much more obvious, even if you don't know the types
of a and b.

 

[Malcolm McLean]

Change the type, don't change the type. It doesn't matter. The argument is
simply that at the time of originally writing the code, and thereafter, the
"bug space" is in practice smaller. There's an extra step of inference
required by your brain when using sizeof (type), and that extra step opens
the door for more bugs. C's type abstractions are few and thin; it's worth
using them to their fullest extent where you can.

I see it as similar to

if(10 == N)

which is justified on the basis that the programmer might accidentally
write

if(N = 10)

it is awful that the last compiles to valid C, admittedly. But in normal
English usage, we say "if N equals 10". The further you get away for normal
usage, the harder the code is to read.

Similarly some people routinely write for loops

for(i=N;i--

on the basis that the test for zero is faster than the test for equality to N.
Except in the very innermost, most time critical loop this is undesireable,
we count up not down, and the condition evaluations shouldn't have side-
effects.

or infinite loops

 

[Tim Rentsch]

I took your opinion to be "My view is that the more natural
readability of sizeof(short) outweighs the fact that [etc]".
I believed, perhaps wrongly, that you had stated this opinion
before and were simply restating it (note, there was nothing
further in the posting). Is that wrong? If so, my apologies.

Yes, that's essentially it.
Okay.

There's no point starting essentially the same sub-thread every
time someone posts a code snippet that contains a call to
malloc(). OTOH newbies shouldn't be led to think that there's a
consensus that the dereferencing style is to be recommended.

If your point is that there are different opinions on the
question, you might want to say it differently, eg, "Note that
not everyone agrees with this viewpoint; for example, IMO ...".
What was written in your earlier posting led me to believe you
meant to have, or renew, a debate on the merits. That is very
different from saying only that there are different schools of
thought in the matter.

 

[Malcolm McLean]

If your point is that there are different opinions on the
question, you might want to say it differently, eg, "Note that
not everyone agrees with this viewpoint; for example, IMO ...".
What was written in your earlier posting led me to believe you
meant to have, or renew, a debate on the merits. That is very
different from saying only that there are different schools of
thought in the matter.

You need to very briefly outline the argument. Just saying "I disagree" isn't very illuminating.
Saying "I disagree because ... but we've discussed this many times" puts everyone in the picture.

It's not as if a sub-thread on the topic is the end of the world. But I don't really have anything new
to say on the subject that most regs haven't heard already, and I don't want to start essentially the
same sub-thread under every code snippet containing a call to a memory allocation function.