[luatex] fio library byte order

[Henri Menke]

On 22/06/20, 10:52, Martin Mareš wrote:
> Hello!
> 
> > Type punning is undefined behaviour.  When you read from a different
> > union member than you wrote to, there is no guarantee that you are
> > actually reading the same memory.
> 
> I beg to disagree.  Generally, type punning causes undefined behavior,
> but there is a couple of specific cases explicitly allowed by the standard.

No, type punning *is* undefined behaviour.

    6.2.6.1 General
    
    7 When a value is stored in a member of an object of union type, the
    bytes of the object representation that do not correspond to that member
    but do correspond to other members take unspecified values.

http://port70.net/~nsz/c/c11/n1570.html#6.2.6.1p7

It's also really unclear to me why people insist on doing this.  The
memcpy trick is safe and because it uses sizeof it also takes care of
alignment and other platform-specifics.  Most (probably all) compilers
will generate the same or even better assembly for the memcpy variant.

> According to paragraph 6.5.7 of the C11 standard:
> 
> (1) A union containing a member of type T can be accessed as type T directly
>     (this also implies that union padding can be inserted only after the
>     members, not before).

This standardese has nothing to do with type punning.  It says that you
can access, e.g. union { int } as int.

> (2) Any object can be accessed as (signed or unsigned) chars.

This standardese refers to casts, e.g.

    int i = 1;
    char *pc = (char *)&i;

While the compiler might generate the same code as for type punning
through a union, the latter is still not specified by the standard.

Cheers, Henri

> 
> 				Have a nice fortnight
> -- 
> Martin `MJ' Mareš                        <mj at ucw.cz>   http://mj.ucw.cz/
> United Computer Wizards, Prague, Czech Republic, Europe, Earth, Universe
> Hex dump:  Where witches put used curses...