Re: [DNG] semantic of sizeof operator in C
On Thu, 13 Jun 2019 08:31:48 +0200 aitor wrote: > En 13 de junio de 2019 7:45:48 Didier Kryn escribió: > > > Le 12/06/2019 à 19:12, s@po a écrit : > >> First of all, I think that this subject derailed to a diferent subject. > >> > >> > >> > >> > >> I Apologise for give my opinion on a concrete subject, because, I never > >> felt it would turn out "to be almost personal.." > > > > Never saw anything personal here and the discussion triggered a > > usefull clarification, beyond the style question :~) > > > > Didier > > > > Yes..., technical discussions are funny :) > > > > Aitor. Ups, Seems that I missunderstood it.. My Apologies for that( ... tux is hiden now, under a BIG Rock.. ).. :) -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C
En 13 de junio de 2019 7:45:48 Didier Kryn escribió: Le 12/06/2019 à 19:12, s@po a écrit : First of all, I think that this subject derailed to a diferent subject. I Apologise for give my opinion on a concrete subject, because, I never felt it would turn out "to be almost personal.." Never saw anything personal here and the discussion triggered a usefull clarification, beyond the style question :~) Didier Yes..., technical discussions are funny :) Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Enviado con AquaMail para Android https://www.mobisystems.com/aqua-mail ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C
Le 12/06/2019 à 19:12, s@po a écrit : First of all, I think that this subject derailed to a diferent subject. I Apologise for give my opinion on a concrete subject, because, I never felt it would turn out "to be almost personal.." Never saw anything personal here and the discussion triggered a usefull clarification, beyond the style question :~) Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)
On Wed, 2019-06-12 at 08:40 -0400, Hendrik Boom wrote: > > More precisely, sizeof(foo) is the spacing of consecutive elements of > type foo. Most importantly for most people, malloc(sizeof(foo)*n) must not cause unexpected things like a kaboom. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C
Hello guys, First of all, I think that this subject derailed to a diferent subject. I Apologise for give my opinion on a concrete subject, because, I never felt it would turn out "to be almost personal.." My Opinion is based on the Idea that we should not create extra complications, When we are ourselfs, defining a fixed size of something kown has a multiple of the minimum size alocable in memory.. In the Case, **only focusing only in the case**.. We had a Array used has a buffer with 512 bytes of fixed size.. So it was a pointer for something multiple of minimum size that could be alocated.. So in this situation sizeof or sizeof '*array', by the way( since sizeof is **not** a function but a unary operator.. ), Doesn't make any sense at all .. Why should we be calculating the size of a buffer, if we ourselfs dictated the fixed size and its a multiple of 'char' type, and also a multiple of 2^n?? Why are we calculating its size in all aplication were it is used, at compile time? You can simply use a MACRO instead.. # define BUFFER_SIZE 512 In the pré-conpilation process, Macro will be substituted in text, And no need to calculate nothing in the code, anny way a lot of pre-processing will occur, wether you want or not.. This was the motiff why I gave my sincere opinion, and nothing more than that, only to try to help @aitor.. Off course, if you have to allocate memory for structs/unions, things could be dynamic a bit.. or at least they were in the past.. To be honest, I don't recall if sizeof '*truct', does padding, or if it suppress bytes by itself right now( I do it by myself in the struct section declaration, since I don't allow the compiler to take "his opinions" has mines.., ... I am the one doing the code.. ), But that is another thing, and not related with the code in cause.. Like @Didier noticed before, In **this concrete case**, it has more to do with Code Style, than anything else!! The code Generated will be similar, But with a Macro seems to me, to be better.. Like I said, you don't be all the time in the code, asking compiler to find the size of something that you, **yourself**, created with fixed size, and a multiple of 2^n bytes, ... you know the size... for sure!! That been Said, I only gave my honest/sincere opinion about the 'sizeof' vs 'Macro', for the **concrete** situation( I don't even read all code..only took a shot at it.. ). I apologize to all of you, ... for the buzz, I afterall, created around this.. Best Regards, -- tux s@po ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C
Le 12/06/2019 à 16:29, Irrwahn a écrit : More precisely, sizeof(foo) is the spacing of consecutive elements of type foo. -- hendrik Thank you Hendrik, that is indeed very aptly phrased! Just for the sake of completeness, the actual language definition takes the usual wordy but precise approach in Standardese: ISO/IEC 9899:2011 | 6.5.3.4 The sizeof and _Alignof operators | [...] | 2 The sizeof operator yields the size (in bytes) of its operand, | which may be an expression or the parenthesized name of a type. | The size is determined from the type of the operand. The result | is an integer. If the type of the operand is a variable length | array type, the operand is evaluated; otherwise, the operand is | not evaluated and the result is an integer constant. | [...] | 4 When sizeof is applied to an operand that has type char, unsigned | char, or signed char, (or a qualified version thereof) the result | is 1. When applied to an operand that has array type, the result is | the total number of bytes in the array. When applied to an operand | that has structure or union type, the result is the total number of | bytes in such an object, including internal and trailing padding. Thanks guys for the neat clarification, in particular that the stucts and unions shall actualy comprise trailing padding bytes when required by alignment. BTW I didn't know of the _Alignof operator. And, sure, for VLAs, the size it evaluated at run time. I'm a big fan of VLAs for dynamic allocation in the stack. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)
Hendrik Boom wrote on 12.06.19 14:40: > On Wed, Jun 12, 2019 at 01:47:42PM +0200, Irrwahn wrote: > >> >> There is nothing wrong here. Gcc reports the size that is necessary to >> store an object of type sesqui_int, including any padding that has been >> applied, e.g. for alignment reasons. An array of n elements of that type >> will in turn always be reported by sizeof as having *exactly* n times >> that size, in bytes. Gcc is therefore in accordance with the language >> definition. > > More precisely, sizeof(foo) is the spacing of consecutive elements of type > foo. > > -- hendrik Thank you Hendrik, that is indeed very aptly phrased! Just for the sake of completeness, the actual language definition takes the usual wordy but precise approach in Standardese: ISO/IEC 9899:2011 | 6.5.3.4 The sizeof and _Alignof operators | [...] | 2 The sizeof operator yields the size (in bytes) of its operand, | which may be an expression or the parenthesized name of a type. | The size is determined from the type of the operand. The result | is an integer. If the type of the operand is a variable length | array type, the operand is evaluated; otherwise, the operand is | not evaluated and the result is an integer constant. | [...] | 4 When sizeof is applied to an operand that has type char, unsigned | char, or signed char, (or a qualified version thereof) the result | is 1. When applied to an operand that has array type, the result is | the total number of bytes in the array. When applied to an operand | that has structure or union type, the result is the total number of | bytes in such an object, including internal and trailing padding. Best regards Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)
On Wed, Jun 12, 2019 at 01:47:42PM +0200, Irrwahn wrote: > > There is nothing wrong here. Gcc reports the size that is necessary to > store an object of type sesqui_int, including any padding that has been > applied, e.g. for alignment reasons. An array of n elements of that type > will in turn always be reported by sizeof as having *exactly* n times > that size, in bytes. Gcc is therefore in accordance with the language > definition. More precisely, sizeof(foo) is the spacing of consecutive elements of type foo. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)
Didier Kryn wrote on 12.06.19 12:15: [...] Hi Didier, please allow me to clear up some apparent misconceptions below. > > What I meant in this discussion is that sizeof() allows to > calculate the number of elements of an array, because we make > assumptions on data layout, but this is an artefact and I don't think it > is specified by the language wether the result is exact or not. > > Let's consider the following type: > > typedef struct {int i; short h} sesqui_int; > > One would naively consider that sizeof(sesqui_int) is equal to 6. > But, with gcc, the value is 8, which looses 2 bytes in which it could > store a short or two chars. This is because this struct must be aligned > on a 4-byte boundary and, if you make an array of these, > sizeof(sesqui_int)*number_of_elements must give the size of the array. > Gcc has chosen to return a wrong sizeof() for the sake of preserving a > naive size arithmetic. There is nothing wrong here. Gcc reports the size that is necessary to store an object of type sesqui_int, including any padding that has been applied, e.g. for alignment reasons. An array of n elements of that type will in turn always be reported by sizeof as having *exactly* n times that size, in bytes. Gcc is therefore in accordance with the language definition. I assume the misunderstanding here was that sizeof should report the minimal size an object would occupy in the absence of any alignment requirements etc. imposed by the actual platform. This is not what sizeof is designed to do. Instead it shall report the *actual* amount of memory required to store such an object. If you expected something else you already made unwarranted assumptions about implementation details that should not matter to you as the programmer. > > Another implementation of the C language might decide to add > headers to arrays, in which it would store the size to perform strict > runtime checks. In this case the size of an array would be larger than > the sum of the sizes of its elements. No, it must not. This is prohibited by the definitions and constraints in the C standard. The introduction of array headers would for example lead to (void *)&array == (void *)&array[0] not always being true, which would contradict the language definition. In other words, your hypothetical implementation would implement some language that is not C, by definition. On a somewhat related note: Any padding present in a struct can never appear at the start of that struct, i. e. the address of an object of structural type is guaranteed to always compare equal to the address of its first member. > > Therefore this use of sizeof(), even though widespread, remains a > trick. Not so. Num_array_elements = sizeof array / sizeof element is neither a trick nor an accident, but rather idiomatic C . It is guaranteed by the C standard (any version) to yield the correct element count. Predicting the behavior of any non-trivial C program would be a crap shot otherwise. Moreover, it would make impossible to reliably allocate dynamic memory for arrays, consider the well-known (and correct) idiom: some_type *arr = malloc(num_elements * sizeof *p); And while we're at it, please let me add some random interesting facts about the sizeof operator one should be aware of: * Being the operand of the sizeof operator is one of the few cases where an array designator does not decay into a pointer to its first element, and a non-array lvalue is not converted to the value stored in the designated object; e.g. the *p in the example above does _not_ dereference p. (All of this is a fancy way of saying that sizeof looks strictly only at the type of its operand, not its value). * Since C99 there is one important exception to the rule that the sizeof operator is evaluated at translation time, and that is when applied to VLAs (variable length arrays) - for obvious reasons. * The parentheses around the operand of sizeof are only mandatory, if said operand is a type name. For ordinary object designators (lvalues) they arguably add unnecessary clutter and may mislead novices into the false belief that sizeof is a function, which it is not. I hope that helped clear things up a bit. Best regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng