[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cb93221b-d4b3-d442-7c8d-97022cfdbe80@tu-dortmund.de>
Date: Tue, 25 Sep 2018 14:58:26 +0200
From: Alexander Lochmann <alexander.lochmann@...dortmund.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [x86] BUG()/BUG_ON() macros cannot be disabled
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
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists