[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] CValue
From: |
Thomas Preud'homme |
Subject: |
Re: [Tinycc-devel] CValue |
Date: |
Sun, 08 Mar 2015 13:15:53 +0800 |
User-agent: |
KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) |
Le jeudi 05 mars 2015, 22:13:17 Edmund Grimley Evans a écrit :
> Can anyone think of an argument for preserving the way TCC currently
> stores an integer constant in one of the following union members?
>
> int i;
> unsigned int ui;
> unsigned int ul; /* address (should be unsigned long on 64 bit cpu) */
> long long ll;
> unsigned long long ull;
Funny, I never thought about it. Digging into the history
(25618c0430b58d1d5522091c83c89cdde83135f1) one can see that there was no such
duplication for integer initially. There is this for float but I suppose it's
to not have more precision than the programmer requested.
>
> To me it seems to make the implementation more complicated while
> inviting people to rely on undefined behaviour such as signed overflow
> and writing to one member of a union then reading from another. The
> obvious thing to do is to use unsigned long long (or uint64_t or
> uintmax_t) for all integer constants, but I've not actually tried
> changing the code.
If there is a lot of such union some space might be saved but I'm not
convinced it's significant. Setting a value in one field and accessing it in
another is forbidden by the C standard I think (aliasing?) and anyway only
make sense for downcasting on little endian target. I don't think the
endianness is such a big problem because this assumption must already be all
over the place but avoiding bug and simplifying the code is a good reason to
get rid of this.
Best regards,
Thomas
signature.asc
Description: This is a digitally signed message part.