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

[Marcelo Tosatti]

On Sun, Sep 12, 2004 at 05:43:12PM +0200, Jean Delvare wrote:
> > 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).

I'm applying these gcc 3.4 changes because they look straightforward to me
and I quite a lot of people were complaining about this.

I dont pretend to accept any further (gcc 3.5 and beyond) changes.

> 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.

Mikael?


-
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/