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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
next prev parent 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