Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Feb 2013 11:16:04 +0100
From:      Christoph Mallon <christoph.mallon@gmx.de>
To:        Andriy Gapon <avg@FreeBSD.org>
Cc:        Kirk McKusick <mckusick@mckusick.com>, freebsd-arch@FreeBSD.org
Subject:   Re: Proposal: Unify printing the function name in panic messages()
Message-ID:  <5118C4E4.6020706@gmx.de>
In-Reply-To: <511622A2.2090601@FreeBSD.org>
References:  <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <511616AC.8080306@gmx.de> <511622A2.2090601@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09.02.2013 11:19, Andriy Gapon wrote:
> on 09/02/2013 11:28 Christoph Mallon said the following:
>> I do not understand, what the problem is.
>> There are bugs and cumbersome code.
>> This simple changes solves it.
> 
> You conveniently omitted some questions of mine.
> I'll reproduce them:
> Well, have you experienced any problems with debugging due to those
> (absent/misleading) function names?  Or do you see many reports about such problems?

I have dropped them, because they are not relevant.
Though, I have answered them, but I'll rephrase it.
There are many easily -- i.e., not needing any manual intervention -- avoidable bugs and inconsistencies in the code, which can be remedied by a simple change.
Further, the change simplifies the user side of panic() a bit.
Does bad code require a bug report to be fixed?
If you think so, then just read "Proposal" in the topic as "Bug report and patch".

> So I conclude that this is indeed a solution in search of a problem.
> And that's exactly why i don't like it:
> - a lot of lines changed for no good reason

Incorrect information is corrected.
Needlessly different ways to achieve the same thing are unified.
panic calls are simplified a bit.

> - code looks uglier / more obfuscated due to macro(s)

As Alfred pointed out, we can just name it panic.
Also the macro is quite similar to the typical assert macro in the way it automatically aggregates additional information.
This does not obfuscate the code.

> - no clear benefit, because there is no clear problem that needs solving

See above.

	Christoph



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5118C4E4.6020706>