From: "Peter T. Breuer" <ptb@it.uc3m.es>
To: "Herbert Rosmanith" <herp@wildsau.idv-edu.uni-linz.ac.at>
Cc: linux-kernel@vger.kernel.org, ptb@it.uc3m.es
Subject: Re: [IDEA+RFC] Possible solution for min()/max() war
Date: Thu, 30 Aug 2001 23:06:55 +0200 (MET DST) [thread overview]
Message-ID: <200108302106.f7UL6t917787@oboe.it.uc3m.es> (raw)
In-Reply-To: <200108302044.f7UKi7c20040@wildsau.idv-edu.uni-linz.ac.at> from "Herbert Rosmanith" at "Aug 30, 2001 10:44:07 pm"
"A month of sundays ago Herbert Rosmanith wrote:"
>
> > if sizeof(typeof(a)) != sizeof(typeof(b))
> > BUG() // sizes differ
>
> this is not neccessarily a problem. should work with char/short char/int
> short/int comparison.
I got the impression that linus wanted two opposite things:
1) every possible bug made to scream out loud until the author
paid special attention to it and put it to bed with a
soothing declaration
2) completely bona fide promotions made to go silent and not
warn at all.
I don't see how he can really see 3arg_min/max as satisfying (2), since
the author will have to look at each and every existing min/max to
decide on a type with which to frontload the new min/max. So I felt
justified in mostly ignoring (2).
On the other hand, he did say something about -Wsignedstuff being too
verbose, so I'm not sure. Maybe the -W really does make noise about
some compares that wouldn't be flagged by the two constraints I
suggested? If so, perhaps that was what he wanted: a weaker and
more closely controlled -Wsignedgunggg.
> only problem seems to be signed/unsigned int comparison.
I don't know how you know that! You could be right - I don't know.
I haven't seen a tight enough specification of the basic problem
for me to be able to begin to formulate a generic solution. I've just
seen some examples, some more convincing than others.
> > const (typeof(a)) _a = ~(typeof(a))0
> > const (typeof(b)) _b = ~(typeof(b))0
> > if _a < 0 && _b > 0 || _a > 0 && b < 0
> > BUG() // one signed, the other unsigned
> > standard_max(a,b)
>
> if sizeof(typeof(a))==sizeof(int) && sizeof(typeof(b))==sizeof(int) &&
> ( _a < 0 && _b > 0 || _a > 0 && b < 0 )
> BUG() // signed unsigned int compare
What makes sizeof(int) so magic? Are you saying that the problems
don't arise between signed long long and unsigned long long? I saw
an example that seemed generic for all signed unsigned comparisons,
namely that signed int and unsigned int are compared as unsigned, so
(unsigned)2 < (signed)-1. Are you saying that signed long and unsigned
long are NOT compared as unsigned iff sizeof(long) != sizeof(int).
Woooo! Who wrote the C spec? No kidding? There is a special clause
for comparisons that use the native machine word?
And I was hoping that somebody could produce some gcc magic
replacement for BUG() that means "don't compile me". Perhaps
a bit of illegal assembler code with a line reference in?
Surely gcc must have something like __builtin_wont_compile()?
It just needs to be a leaf of the RTL that evokes a compile error.
Peter
next prev parent reply other threads:[~2001-08-30 21:07 UTC|newest]
Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-30 20:44 [IDEA+RFC] Possible solution for min()/max() war Herbert Rosmanith
2001-08-30 21:06 ` Peter T. Breuer [this message]
2001-08-30 21:14 ` David Woodhouse
2001-08-30 21:32 ` Peter T. Breuer
2001-08-30 21:47 ` David Woodhouse
2001-08-30 21:56 ` Peter T. Breuer
2001-08-30 22:13 ` David Woodhouse
2001-08-30 22:47 ` Peter T. Breuer
2001-08-30 23:02 ` David Woodhouse
2001-08-31 0:08 ` Daniel Phillips
2001-08-30 21:49 ` Mark Zealey
2001-08-30 22:06 ` Peter T. Breuer
2001-08-30 22:14 ` Mark Zealey
2001-08-31 7:04 ` Herbert Rosmanith
2001-08-30 21:17 ` Richard B. Johnson
2001-08-30 21:45 ` Thomas Dodd
2001-08-30 21:46 ` Peter T. Breuer
2001-08-30 23:16 ` David Woodhouse
2001-08-30 23:33 ` David Wagner
2001-08-31 11:18 ` Bernd Schmidt
[not found] <m2bskndlkt.fsf@sympatico.ca>
2001-09-07 17:39 ` Peter T. Breuer
-- strict thread matches above, loose matches on Subject: below --
2001-09-06 1:51 Rick Hohensee
2001-09-06 10:12 ` VDA
2001-09-04 13:17 Petr Vandrovec
2001-09-04 9:09 VDA
2001-09-03 23:16 David desJardins
2001-09-03 20:35 David desJardins
2001-09-04 8:08 ` VDA
[not found] <fa.eeq0k8v.1v28iaa@ifi.uio.no>
2001-08-31 18:40 ` Ted Unangst
2001-08-31 18:29 Andy Chou
2001-08-31 18:52 ` Roman Zippel
2001-08-31 18:24 Herbert Rosmanith
2001-08-31 18:13 Herbert Rosmanith
2001-08-31 17:41 Herbert Rosmanith
2001-08-31 17:57 ` Rik van Riel
[not found] <fa.ehba65v.10i6abc@ifi.uio.no>
[not found] ` <fa.odqvefv.g4k4j6@ifi.uio.no>
2001-08-31 15:45 ` ctm
2001-08-31 16:57 ` Roman Zippel
2001-08-31 14:28 Herbert Rosmanith
2001-08-31 14:37 ` Herbert Rosmanith
2001-08-31 14:28 Martin Knoblauch
2001-08-31 2:48 Rick Hohensee
2001-08-31 2:34 Andy Chou
[not found] <20010830174227.A10673@furble>
2001-08-31 1:19 ` Peter T. Breuer
2001-08-31 2:10 ` Peter T. Breuer
2001-08-31 7:43 ` Jonathan Lundell
2001-08-31 8:27 ` Alex Bligh - linux-kernel
[not found] <791753058.999219857@[169.254.198.40]>
2001-08-31 0:57 ` Peter T. Breuer
2001-08-30 20:35 Herbert Rosmanith
2001-08-30 17:32 mike_phillips
2001-08-30 17:45 ` Ion Badulescu
2001-08-30 9:56 Herbert Rosmanith
2001-08-30 13:09 ` Helge Hafting
[not found] <200108291905.f7TJ59T11456@wildsau.idv-edu.uni-linz.ac.at>
2001-08-29 19:11 ` Herbert Rosmanith
2001-08-29 1:33 Ignacio Vazquez-Abrams
[not found] <200108281746.f7SHk1O27199@lists.us.dell.com>
2001-08-28 19:33 ` Brad Chapman
2001-08-28 19:02 ` David Lang
2001-08-28 20:38 ` Brad Chapman
2001-08-28 19:25 ` David Lang
2001-08-28 20:34 ` Andreas Schwab
2001-08-28 20:42 ` Brad Chapman
2001-08-28 21:04 ` Christopher Friesen
2001-08-29 9:03 ` Helge Hafting
[not found] <20010825024248.J8296@router.ranmachan.dyndns.org>
2001-08-25 0:54 ` Brad Chapman
[not found] <20010825021651.I8296@router.ranmachan.dyndns.org>
2001-08-25 0:21 ` Brad Chapman
2001-08-24 22:42 Brad Chapman
2001-08-24 23:21 ` Ben LaHaise
2001-08-24 23:58 ` Brad Chapman
2001-08-25 0:13 ` Alexander Viro
2001-08-25 0:25 ` Brad Chapman
2001-08-25 0:34 ` Alexander Viro
2001-08-25 0:53 ` Brad Chapman
2001-08-25 1:15 ` Alexander Viro
2001-08-25 11:21 ` Brad Chapman
2001-08-27 0:02 ` Rusty Russell
2001-08-28 4:59 ` Linus Torvalds
2001-08-28 5:20 ` Alexander Viro
2001-08-28 5:51 ` Linus Torvalds
2001-08-28 11:10 ` Alan Cox
2001-08-28 14:15 ` Linus Torvalds
2001-08-28 20:06 ` John Alvord
2001-08-28 12:42 ` Roman Zippel
2001-08-28 13:27 ` Linus Torvalds
2001-08-28 14:19 ` Roman Zippel
2001-08-28 15:14 ` Linus Torvalds
2001-08-28 15:44 ` Henning P. Schmiedehausen
2001-08-28 15:55 ` Russell King
2001-08-28 16:05 ` Alan Cox
2001-08-28 16:53 ` Roman Zippel
2001-08-28 16:39 ` Roman Zippel
2001-08-28 21:51 ` Mike Castle
2001-08-29 0:33 ` Daniel Phillips
2001-08-29 1:13 ` Linus Torvalds
2001-08-29 15:42 ` Daniel Phillips
2001-08-29 16:02 ` David Lang
2001-08-29 23:49 ` Daniel Phillips
2001-08-30 2:05 ` Bill Rugolsky Jr.
2001-08-30 3:28 ` Linus Torvalds
2001-08-30 13:10 ` Ion Badulescu
2001-08-30 13:17 ` David Woodhouse
2001-08-30 13:26 ` Ion Badulescu
2001-08-30 16:09 ` Linus Torvalds
2001-08-30 16:28 ` Ion Badulescu
2001-08-31 12:50 ` Jamie Lokier
2001-08-31 13:45 ` Roman Zippel
2001-08-31 16:27 ` Jamie Lokier
2001-08-30 16:31 ` Ben LaHaise
2001-08-30 16:38 ` Peter T. Breuer
2001-08-30 19:51 ` David Weinehall
2001-08-30 20:16 ` Peter T. Breuer
2001-08-30 20:31 ` Daniel Phillips
[not found] ` <mit.lcs.mail.linux-kernel/200108301638.SAA04923@nbd.it.uc3m.es>
2001-08-30 22:42 ` Patrick J. LoPresti
2001-08-30 23:27 ` Peter T. Breuer
2001-08-31 0:55 ` Linus Torvalds
2001-08-31 1:28 ` Peter T. Breuer
2001-08-31 13:22 ` Peter T. Breuer
2001-08-31 14:02 ` Linus Torvalds
2001-08-31 15:34 ` Peter T. Breuer
2001-08-31 12:01 ` Roman Zippel
2001-08-31 12:13 ` Peter T. Breuer
2001-08-31 12:58 ` Roman Zippel
2001-08-31 13:29 ` Peter T. Breuer
2001-08-31 14:12 ` Roman Zippel
2001-08-31 14:28 ` Peter T. Breuer
2001-08-31 16:30 ` Roman Zippel
2001-09-07 0:52 ` Bill Pringlemeir
2001-09-07 7:26 ` Peter T. Breuer
2001-09-07 12:28 ` Horst von Brand
2001-09-07 18:03 ` Mark H. Wood
2001-09-07 10:58 ` Peter T. Breuer
2001-09-07 14:39 ` Bill Pringlemeir
2001-09-07 15:17 ` Peter T. Breuer
2001-08-30 13:49 ` Roman Zippel
2001-08-30 16:21 ` Linus Torvalds
2001-08-30 16:41 ` Christopher Friesen
2001-08-30 16:50 ` Linus Torvalds
2001-08-30 17:13 ` Roman Zippel
2001-08-31 1:28 ` Ion Badulescu
2001-08-31 5:08 ` Linus Torvalds
2001-08-31 12:37 ` Jamie Lokier
2001-08-31 13:54 ` Linus Torvalds
2001-08-30 17:01 ` Daniel Phillips
2001-08-30 17:03 ` Peter T. Breuer
2001-08-30 17:26 ` Daniel Phillips
2001-08-31 8:04 ` Kai Henningsen
2001-08-30 21:16 ` Graham Murray
2001-08-30 21:47 ` David Weinehall
2001-08-31 10:10 ` Helge Hafting
[not found] ` <mit.lcs.mail.linux-kernel/m266b51c5c.fsf@barnowl.demon.co.uk>
2001-08-30 22:26 ` Patrick J. LoPresti
2001-08-28 16:09 ` Andreas Schwab
2001-08-28 16:47 ` Roman Zippel
2001-08-28 17:12 ` Bill Rugolsky Jr.
2001-08-28 17:28 ` Roman Zippel
2001-08-28 17:29 ` Richard B. Johnson
2001-08-26 17:59 ` Bill Pringlemeir
2001-08-24 23:59 ` Brad Chapman
2001-08-25 0:07 ` David S. Miller
2001-08-25 0:18 ` Brad Chapman
2001-08-25 0:23 ` David S. Miller
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=200108302106.f7UL6t917787@oboe.it.uc3m.es \
--to=ptb@it.uc3m.es \
--cc=herp@wildsau.idv-edu.uni-linz.ac.at \
--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;
as well as URLs for NNTP newsgroup(s).