X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: Upgrading from a bad C compiler Date: Sat, 28 Jul 2012 15:28:28 -0400 Organization: Aioe.org NNTP Server Lines: 90 Message-ID: References: <17d4b525-2c31-4c20-b3c5-a7118343e9a5 AT googlegroups DOT com> <3331145d-900b-4bef-8ad0-f533f0b4a17b AT googlegroups DOT com> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org X-Complaints-To: abuse AT aioe DOT org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.2001 X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Microsoft Outlook Express 6.00.2800.2001 X-Priority: 3 X-MSMail-Priority: Normal Bytes: 4886 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Hans-Bernhard Bröker" 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