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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.