public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cannon <ajc@gmx.net>
To: "Magnus Naeslund(f)" <mag@fbab.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: macro conflict
Date: Fri, 24 Aug 2001 01:18:58 +0200	[thread overview]
Message-ID: <3B858F62.AD7CED14@gmx.net> (raw)
In-Reply-To: <20010823143440.G20693@mindspring.com> <3B85615A.58920036@timesn.com> <03fc01c12c10$8155b060$020a0a0a@totalmef>



"Magnus Naeslund(f)" wrote:
> 
> From: <raybry@timesn.com>
> > Without digging through the archives to see if this has already
> > been suggested (if so, I apologize), why can't the following be done:
> >
> > min(x,y) = ({typeof((x)) __x=(x), __y=(y); (__x < __y) ? __x : __y})
> >
> > That gets you the correct "evaluate the args once" semantics and gives
> > you control over typing (the comparison is done in the type of the
> > first argument) and we don't have to change a zillion drivers.
> >
> > (typeof() is a gcc extension.)
> >
> 
> But then again, how do you know it's the type of x we want, maybe we want
> type of y, that is and signed char (not an int like x).
> Talk about hidden buffer overflow stuff :)


What about this then:

#define min(x,y) ({typeof(x) __x=(x); typeof(y) __y=(y); (__x < __y) ?
__x : __y})

This is guaranteed to work the same as the old min/max in all cases but
without side effects. You can still force the comparison to be done with
a certain type by casting the arguments first:

#define typed_min(type, x, y) (min((type)(x), (type)(y)))

...although, if the type used for the comparison is so critical you
maybe shouldn't be hiding it in a macro anyway.

Andrew

  parent reply	other threads:[~2001-08-23 23:15 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-23 19:03 macro conflict J. Imlay
2001-08-23 19:21 ` Alan Cox
2001-08-23 19:34 ` Tim Walberg
2001-08-23 20:01   ` Alan Cox
2001-08-23 20:02   ` raybry
2001-08-23 20:16     ` Magnus Naeslund(f)
2001-08-23 20:27       ` Alan Cox
2001-08-23 20:29         ` Magnus Naeslund(f)
2001-08-23 23:18       ` Andrew Cannon [this message]
2001-08-23 23:37         ` Magnus Naeslund(f)
2001-08-23 23:35       ` Roman Zippel
2001-08-24  1:42     ` Camiel Vanderhoeven
2001-08-24 13:03 ` David Woodhouse
2001-08-24 13:15   ` Keith Owens
2001-08-24 13:17     ` David Woodhouse
2001-08-24 14:20       ` Bill Pringlemeir
2001-08-24 21:17         ` Roman Zippel
2001-08-24 13:34   ` Richard B. Johnson
2001-08-24 18:20     ` David Wagner
2001-08-24 17:25   ` Alex Bligh - linux-kernel
2001-08-24 17:34   ` David Woodhouse
2001-08-24 18:12     ` Bill Pringlemeir

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=3B858F62.AD7CED14@gmx.net \
    --to=ajc@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mag@fbab.net \
    /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