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] backups from ext4 to ntfs - extended attributes and access control lists
On 2019-05-28 15:53, Rick Moen wrote: [1] Last I heard, Microsoft OSes had nothing quite like a symlink, which was one reason why Cygwin was a bit of a kludge. (They may have fixed that; I wouldn't know ... Yes, they are possible. Notes: https://blog.spiralofhope.com/?p=13539 Tested in Windows 10, it's called a "Junction", using: mklink /J ___ 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 *) == (void *)[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
Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists
...on Tue, May 28, 2019 at 04:17:44PM -0700, Bruce Ferrell wrote: > You *could* make a tarball and copy that to NTFS. Imperfect but no semantic > loss that way Last I checked, --no-xattrs --no-acls --no-selinux still was the default for GNU tar. So if you want to keep any of those, you need tho enable them, as appropriate, when creating or extracting an archive. Alex. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] simple-netaid from scratch
Hi Didier, En 12 de junio de 2019 7:40:08 Didier Kryn escribió: sizeof() is not a real function. Its syntax makes it look like a function but it is not. Its argument can be either a variable or a type (which no function can have). It is evaluated at compile time - which is equivalent to replacing it with the litteral value. Didier But, in this concrete case, the size can be evaluated at compile time because the memory is asigned statically by using a char array (instead of a char* pointer). In the case of a dinamic memory asignment (runtime), the size would be the value of the N variable used in the malloc function. BTW, i recently added the systray icon to simple-netaid: https://git.devuan.org/aitor_czr/simple-netaid/blob/master/screenshots/systray-icon.png Cheers, 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
