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

From: "Andrew Cannon" <ajc@gmx.net>
>
> 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:
>
[snip]

Well it's closer but not really what i want.
The min/max_type is maybe the way to go, but the above can still bit you if
the types differ. Consider max().

char lut[256];
int   c1 = 256+rand()%256;
char  c2 = rand()%256;
char dest = lut[max(c2,c1)];

Won't c1 still be returned untruncated?

Ofcourse one will use another construct for these kinds of checks, but maybe
your brain collapses just for a second and think that this will return a
char.

OK ok bad example, but maybe you see that i have a point here somewhere
(under my chair? :) ).

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2001-08-23 23:35 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
2001-08-23 23:37         ` Magnus Naeslund(f) [this message]
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='057601c12c2c$9877b650$020a0a0a@totalmef' \
    --to=mag@fbab.net \
    --cc=ajc@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    /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