From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Mikael Pettersson <mikpe@csd.uu.se>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2.4.28-pre3] I2C driver core gcc-3.4 fixes
Date: Tue, 14 Sep 2004 15:19:16 -0300 [thread overview]
Message-ID: <20040914181916.GA30422@logos.cnet> (raw)
In-Reply-To: <20040912174312.5ea8d2ef.khali@linux-fr.org>
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?
next prev parent reply other threads:[~2004-09-14 20:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-12 15:10 [PATCH][2.4.28-pre3] I2C driver core gcc-3.4 fixes Mikael Pettersson
2004-09-12 15:43 ` Jean Delvare
2004-09-14 18:19 ` Marcelo Tosatti [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-09-12 11:25 Mikael Pettersson
2004-09-12 13:44 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040914181916.GA30422@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@csd.uu.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox