Mail Archives: djgpp/2012/07/28/15:45:14
"Hans-Bernhard Bröker" <HBBroeker AT t-online DOT de> wrote in message
news:a7htthFse5U1 AT mid DOT dfncis DOT de...
> On 27.07.2012 22:09, Rod Pemberton wrote:
> > I didn't know that, but I avoid sizeof().
>
> Frankly, that's a pretty silly position.
>
Why?
I've not had any problems with that position in two decades of C
programming. Should I have had?
I have the same perspective about use of sizeof() as others do about use of
casts. I'm not saying I don't use sizeof(). I use it in the various ways I
stated back a few posts. sizeof() is clearly adequate for returning the
correct sizes of basic types. But, my usage of it is minimal, only where
absolutely needed.
> > One could definately argue C shouldn't "know" anything about the
> > padding, i.e., it can be argued that padding is outside of C's "sphere
> > of knowledge".
>
> Whether or not that argument can possibly make sense depends on what you
> mean by "C" here: the C source code, the C translation tools, or some
> combination of the two?
>
> Yes, C source code must not know such things all by itself. But the C
> tools obviously must know
Some aspect of C compilation needs to "know" the sizes of C objects, yes.
Do the "C tools" need to "know"? Or, does just the C compiler need to
"know"? I'd say that depends on the compiler design. But, I'm not sure why
any compiler would pass sizes of objects to secondary tools. The sizes are
known at compile time by the compiler. Usually, padding and alignment
directives are inserted into the assembly. The C compiler can - design
dependent - do that without any the "C tools" ever "knowing" what size the
objects are. They just "know" to pad or align to a certain size or
boundary.
So, you're classifying an intermediate assembler as a "C translation
tool"... Not doing so may change your understanding of what "possibly
makes sense".
> (or they couldn't support structs at all).
Untrue. All structs, unions, typedef's would simply be byte aligned and
without padding.
> But sometimes the C source needs a way to inquire the info from the C
> tools, e.g. to dynamically allocate (arrays of) structs. The sizeof()
> operator is this way.
Yes, I already mentioned that. See "However, it's sometimes convenient ..."
back a couple of posts.
> > Either way, I see sizeof() leading to problems.
>
> You got that backwards. sizeof() is what solves those problems.
>
As you noted, it clearly doesn't solve the "people have to sum the sizes of
individual elements themselves" problem. That was my point. Sizeof() only
works for one of two expectations for it.
Why would a C programmer assume sizeof() for a union or struct returns
anything other than exactly the "sum of the sizes of the individual
elements"? I'd say that's the most likely expectation of someone using
sizeof() on a struct, union, or typedef. That's what it does for int's,
char's, long's, etc. Yes? Can C return 7 due to padding for sizeof() of an
unsigned long? (Horrors...) What about sizeof() of a char? What if it
didn't return one ... ? If someone takes a sizeof() of a struct that has
three unsigned long's, they don't expect some astronomical value because of
padding or alignment, e.g., perhaps returning 64 on 64-bit aligned
machine... Do they? No, of course not. That's something that is learned.
Backwards? No, I just think I understand the situation differently.
Sizeof() will only work correctly for one of two situations, but not both,
as you noted too. One of the two methods was chosen for C. It doesn't
matter to me which. I avoid sizeof() - using it only on basic types. But,
a second sizeof() that correctly worked for the other situation also
could've been introduced for C, regardless of which one was chosen for C.
Rod Pemberton
- Raw text -