Re: [PATCH 2/15 v2] Unhardcode byte size being 8 bits.

["Alexey Zaytsev" <alexey.zaytsev@gmail.com>]

On Thu, Dec 18, 2008 at 02:33, David Given <dg@cowlark.com> wrote:
> Alexey Zaytsev wrote:
> [...]
>> This problem may be addressed by changing bits_to_bytes to
>> static inline int bits_to_bytes(int bits)
>> {
>>        return bits >= 0 ? bits / bits_in_char : -1;
>> }
>
> That's fine by me (although I've been using my version for ages now with
> no apparent problems --- just out of interest, Clue is now using Sparse
> to compile C into Lua, Javascript, Perl 5, Common Lisp, C and Java
> moderately successfully).
Just try to run sparse over the Linux kernel. It fireas at least at
void * pointer manipulation and (some?) offsetof()'s. Maybe
somewhere else.

>
>> But it seems there is also a bug in sparse, as in
>> ctype_declaration[] the bit_size of void_ctype is
>> set to NULL, while gcc assumes sizeof(void) being 1.
>> Currently sparse would generate wrong code for:
> [...]
>> unsigned long test1(void *p)
>> {
>>         return sizeof(*p);
>> }
>
> TBH, I don't think that's legal --- I know of several compilers that
> will refuse to compile it, and gcc -pedantic produces a warning, which
> means it probably falls into the 'undefined behaviour' bucket of the
> standard. I can't find anything that specifically talks about sizeof
> void, but 6.3.2.2.1 prohibits doing *anything* with the result of an
> expression of type void, which sort of applies here.
>
> Of course, I'm thinking about this from the sparse-as-a-compiler point
> of view, where you're probably more interested in replicating gcc's
> behaviour.

This seems to be legal, and quite popular in the Linux kernel. GNU C defines
sizeof(void) being 1.And as it has the -Wpointer-arith flag, this kind of stuff
may be caught without sparse if deemed undesirable.

P.S:
Please, sign off this patch and the one adding type information to
struct instruction.