public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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?



  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