Generic Linux architectural discussions
 help / color / mirror / Atom feed
From: Alexander Lochmann <alexander.lochmann@tu-dortmund.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [x86] BUG()/BUG_ON() macros cannot be disabled
Date: Tue, 25 Sep 2018 14:58:26 +0200	[thread overview]
Message-ID: <cb93221b-d4b3-d442-7c8d-97022cfdbe80@tu-dortmund.de> (raw)
In-Reply-To: <CAK8P3a2to1LbSNizeSHE3vHaCtp5PSrVFAzy5X2mE49x3tPbxg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1325 bytes --]



Am 25.09.2018 um 14:20 schrieb Arnd Bergmann:
> 
> I think it's the most reasonable implementation, otherwise a
> function like
> 
> int something(void)
> {
>       if (x)
>          return 0;
>      else
>           BUG();
> }
> 
> will return an uninitialized value.
> 
> The arch specific implementations usually just contain a trapping
> instruction. With CONFIG_BUG() you get a nice console output
> that indicates where this happened, but without CONFIG_BUG(),
> this is just reported as an invalid instruction (if CONFIG_PRINTK
> is still enabled), killing the current process.
> 
>        Arnd
> 
I see. In that case, you should really update the documentation and help
page of CONFIG_BUG. In its current version it is misleading. It can be
understood as 'It disables that macro completely.'.

Although I know what the purpose of BUG()/BUG_ON() is, I would not
consider the above example as valid C code....
Defining BUG as an endless loop to overcome GCC warnings about not
returning a value is a dirty hack for me.

- Alex

-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2018-09-25 12:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 11:35 [x86] BUG()/BUG_ON() macros cannot be disabled Alexander Lochmann
2018-09-25 11:35 ` Alexander Lochmann
2018-09-25 12:06 ` Arnd Bergmann
2018-09-25 12:06   ` Arnd Bergmann
2018-09-25 12:13   ` Alexander Lochmann
2018-09-25 12:13     ` Alexander Lochmann
2018-09-25 12:20     ` Arnd Bergmann
2018-09-25 12:20       ` Arnd Bergmann
2018-09-25 12:58       ` Alexander Lochmann [this message]
2018-09-25 12:58         ` Alexander Lochmann
2018-09-25 12:31   ` Alexander Stein
2018-09-25 12:31     ` Alexander Stein

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=cb93221b-d4b3-d442-7c8d-97022cfdbe80@tu-dortmund.de \
    --to=alexander.lochmann@tu-dortmund.de \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --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