On Thu, Dec 18, 2008 at 02:33, David Given <dg@xxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
