Re: [ANN] Lua 5.4.0 ... struct with variable size array ... C90 support

[Francisco Olarte <folarte@...>]

On Fri, May 15, 2020 at 1:45 PM Philippe Verdy <verdyp@gmail.com> wrote:
>> >> aligned type like char, i.e., how about { char a; int b[] }?
>> > Yes, not a problem, the "char a" has no alignment constraints: sizeof(a)=1 and alignof(a) =1
>> > But given that for example sizeof(int)=4 and alignof(int)=4 mayu be needed with some platform, b will be prepadded. with 3 bytes. The total structure has then 8 bytes, not 5
>>
>> Are you sure? I would swear it is "4 not 1", and not "8 not 5":
>>
>> gcc version 8.3.0 (Debian 8.3.0-6)
>> $ cat kk.c
>> #include <stdio.h>
>> struct {  char a;  int b[]; } x;
>> int main(int ac, char **av) {
>>   printf("%d\n", (int)sizeof(x));
>>   return 0;
>> }
>> $ gcc kk.c
>> $ ./a.out
>> 4
>
>
> You are NOT testing the same thing:

Yes I was, because I copied the definition from the copy of my
original definition you copied on your reply.

> here the size is the size of char plus the *prepended* padding  before a possible int (whose sizeof and alignof are 4, so there are 3 prepended bytes *before* the member array b; but not really after member a which does not need it at all).

You are the only one using prepended/appended and such exotic
definitons. The original link only talked about padding.


> I know that there exists platforms whose "byte" addressable units is smaller than an octet: some controlers using nibbles, and some platforms even allow bit addressable memory,

That's moot for standard C, it needs CHAR_BITS at least 8.

> I'm sure there will be very fast CPU that will restore bit-addressable memory and serial links everywhere because it will allow faster clocks and lower energy dissipation (and external memory chips using serial links already exist for the same reason: accelerate the transfert rates with the same or improved reliability at larger distances. This is already why there are now optical links working reliably at 10Gbps, 100Gbps, and soon we'll have 1Mbps optical links: parallel buses will no longer be the best choice except inside the same chip.

Serial buses are faster because of delay skew in paralell. But that's
a low level issue which anyone knowing it's propagation equations
knows. Not in the domain of C language and computer science, its an
electronics / communications issue.

> The C/C++ standards also do not require the native "int" to have a defined bitsize,

but it requires at least 16.

> bits which could be useful as autocorrecting codes for transmission on very fast links.

again, C compiler is forced to hide all this stuff.

> This means that a char could still have an 8-bit value range, but 10-bit storage length with 2 autocorrecting bits (autocorrection will occur when loading the value into an 8-bit register,

Bits are not autocorrecting. That would be a 10 bit autocorrecting
storage value.


> * 1==sizeof(char)<=sizeof(wide char) , and
> * 1<=sizeof(boolean)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long),    and

You forgot 16 <= sizoefint, 32 <=sizeof  long.

> * sizeof(type)== sizeof(signed type)==sizeof(unsigned type) for all integer types (including char, boolean, short, long, long long, and pointer diffs), and
> * a "pointer diff" type is defined as one of the available integer types, and

> * 1<=sizeof(pointer)<=sizeof(pointer diff) and

I think you are pulling this out of nowhere, to be polite. I doubt
sizeof(pointer) has any relation with an integral type size.

And I'm not too sure if it was standard compliant, but I've certainly
worked, and you surely remember, msdos large memory model, where
sizeof(void *)==4 and sizeof(ptr_diff_t)==2. Ptr_diff_t has to be able
to hold the largest defined value for a valid pointer diff, and no
more ( although an implementro an choose any larger size should she
want it ).

> * the "char" type should have a value domain at least 6-bit wide (only if unsigned),

I'm nearly sure CHAR_BIT must be at least 8.

> * for all integer types, the negation fo a value may not necessarily give a distinct value and there's no warranty that: abs(value)==abs(-value),

> * the cardinality of the valid domain range of integer types is not necessarily a power of 2

Again, I'm nearly sure C has to work like it has binary arithmetic. Of
course, it's implementation defined how to do it, as log as the user
sees it.

-- Some platforms may use only BCD integers: a single "char" could as
well store only units 0 to 99 (using 8 bits internally, it would be
unsigned in that case), or -499 to 499, or 0 to 9999 (using 12 bits
internally), or 0 to 9999 (using 16 bits internally).

I think they cannot do that. They need at least 16 bits precision on
integer, so they would need to use whatever bits / trits they need to
reach at least that. And they need to operate as if they were binary
and support binary operations. They can perfectly store the numbers in
sign plus roman numerals, if they want to, they just cannot expose
that in C. Thay can do it in other languages, but not in standard C.


> The C/C++ requires no alignment at all for any type.

I assume you consider align 1 = no alignment.

> if alignment is needed and used by the compiler for its own performance goals (and measurable in "bytes" with "sizeof") it is only with *prepadding* before the type, no type is followed by trailing padding bytes.

That "prepadding" is, IMNSHO, an invention of yours.

Padding can be before or after or wherever the compiler choose to lay
it. And there is this little condition of the sizeof an array being
the array size times the element sizeof which forces compiler in
exotic archs to do strange things.


Francisco Olarte.
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org