Re: [PATCH][2.4.28-pre3] I2C driver core gcc-3.4 fixes

[Jean Delvare]

> Yes, it results in code doing void* pointer arithmetic, but
> the kernel uses that particular gcc extension in a lot of
> places. It's ugly but known to work exactly like char*.

OK, I didn't know that. Thanks for the info.

> However, I'm no fan of void* arithmetic. Would code like
> buffer = (void*)((char*)buffer + buflen); make you happier?

Well, it makes things even uglier IMHO, so let's not do it.

> >After a quick look at the code I'd say that the buffer-like
> >parameters involved should be declared as char* instead of void* in
> >the first place, which would effectively make all further casts
> >unnecessary, and still work exactly as before.
> 
> Maybe, but that's potentially a much larger change. I'm just
> looking for the minimal changes to make the 2.4 kernel safe for
> gcc-3.4 and later (cast-as-lvalue is an error in gcc-3.5/4.0).

I'm not much in favor of "fixing" old code just to make it gcc-3.5
compliant, especially when at the same time we won't clean it up,
potentially resulting in less readable code. I would be perfectly happy
with being able to compile 2.4 kernels with gcc versions up to 3.3 and
not above. What's the exact benefit of changing old and stable code in
the end of its life cycle for it to support future compilers? I don't
get it (but at the same time I am not the one deciding here).

This was a general comment. For the specific changes you propose, if
void* works like char* when it comes to arithmetics, it looks safe and
as such is (technically) fine with me.

Thanks.

-- 
Jean "Khali" Delvare
http://khali.linux-fr.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/