linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] debug: fix BUILD_BUG_ON() for non-constant expressions
Date: Tue, 19 Aug 2008 19:33:59 +0300	[thread overview]
Message-ID: <48AAF5F7.6040709@panasas.com> (raw)
In-Reply-To: <20080819133422.GA24369@elte.hu>

Ingo Molnar wrote:
> * Boaz Harrosh <bharrosh@panasas.com> wrote:
> 
>>> Link time warnings are easy enough to miss.
>>>
>>> So unless there's a better way of doing it all at compile time (i'd 
>>> really prefer that!) i'd prefer the link time error about botched 
>>> BUILD_BUG_ON() conditions - as my commits introduce.
>>>
>>> 	Ingo
>>> --
>> #define BUILD_BUG_ON(condition)						\
>> do {
>> 	enum { bad = !!(condition)}; 									\
>> 	static struct { char arr[1 - 2*bad]; } x __maybe_unused;	\
>> } while(0)
>>
>> the enum definition will not let in anything not compile-time constant.
> 
> nice trick!
> 
>> But then I fail on: (include/linux/virtio_config.h:99)
>>
>> 	if (__builtin_constant_p(fbit))
>> 		BUILD_BUG_ON(fbit >= 32);
>>
>> is that code broken?
> 
> hmm ... that's a bit sad, gcc ought to have been able to figure this 
> out. Can this be fixed somehow, without losing the strength of the 
> checking here? I think we should not change BUILD_BUG_ON() to make it 
> less useful.
> 
> 	Ingo

The BUILD_BUG_ON I proposed is not less useful. Actually with current
BUILD_BUG_ON above code does nothing, since fbit is a function parameter
it will translate to nothing. Certainly it will not check the size of passed
parameter, since that was converted on the stack to unsigned int. So my
definition will catch the bad programing here.

If the user of virtio_has_feature() must pass a compile-time constant then
it must be converted to a MACRO, and then the BUILD_BUG_ON will work.
Or it should be changed to a BUG_ON() if fbit is a runtime variable.

>From what I understood this is what you wanted, some way to make sure
a BUILD_BUG_ON will check that the check is actually useful (compile-time)
and is not silently ignored.

Same thing at the other place I sent.

Boaz

  reply	other threads:[~2008-08-19 16:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-16 10:09 [PATCH] BUILD_BUG_ON sucks Alexey Dobriyan
2008-08-16 10:55 ` Rusty Russell
2008-08-16 20:07   ` Linus Torvalds
2008-08-17 10:32     ` [PATCH] debug: fix BUILD_BUG_ON() for non-constant expressions Ingo Molnar
2008-08-17 16:56       ` Linus Torvalds
2008-08-17 17:33         ` Ingo Molnar
2008-08-17 17:53           ` Ingo Molnar
2008-08-17 18:39           ` Linus Torvalds
2008-08-17 18:45             ` Ingo Molnar
2008-08-18  1:09           ` Rusty Russell
2008-08-18  7:54             ` Ingo Molnar
2008-08-18  9:55               ` Boaz Harrosh
2008-08-18 12:32                 ` Boaz Harrosh
2008-08-19 13:34                 ` Ingo Molnar
2008-08-19 16:33                   ` Boaz Harrosh [this message]
2008-08-20 10:59                     ` Ingo Molnar
2008-08-20 12:31                       ` Boaz Harrosh
2008-08-20 12:39                         ` adobriyan
2008-08-20 13:07                           ` Boaz Harrosh
2008-08-21 12:17                         ` Ingo Molnar
2008-08-25  1:19                     ` Rusty Russell
2008-08-20 13:21       ` Boaz Harrosh
2008-08-16 17:46 ` [PATCH] BUILD_BUG_ON sucks Andrew Morton
2008-08-17 12:19   ` Theodore Tso
2008-08-17 16:33     ` Andrew Morton

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=48AAF5F7.6040709@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.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).