Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Nov 2009 23:24:28 +0300
From:      pluknet <pluknet@gmail.com>
To:        =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= <des@des.no>
Cc:        Alexander Best <alexbestms@wwu.de>, Giorgos Keramidas <keramida@freebsd.org>, Nate Eldredge <nate@thatsmathematics.com>, freebsd-hackers@freebsd.org
Subject:   Re: [patch] burncd: honour for envar SPEED
Message-ID:  <a31046fc0911101224i4550e3a4g2af73e5ff1828a3f@mail.gmail.com>
In-Reply-To: <86y6me2l54.fsf@ds4.des.no>
References:  <permail-200911101617381e86ffa80000015a-a_best01@message-id.uni-muenster.de> <86y6me2l54.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
2009/11/10 Dag-Erling Sm=F8rgrav <des@des.no>:
> Alexander Best <alexbestms@wwu.de> writes:
>> you're right. hundreds of functions cause segfaults when arg or args
>> are NULL. =A0either we add safety checks for all of them (massive
>> overhead) or just leave them the way they are.
>
> The consensus in the C community is that adding such checks does more
> harm than good, because a NULL pointer is usually a symptom of a bug
> somewhere else in the application, and checking for a NULL pointer will
> either hide that bug or trigger another error somewhere down the line,
> possibly making the real bug harder to find, rather than easier.
>

And which is a way some well known OS' developers like to choose to
fix sec.holes. No cookie.
P.S. I apologize for flaming on this.

> (next week's topic: the return value of malloc(0)...)
>
> DES
> --
> Dag-Erling Sm=F8rgrav - des@des.no


--=20
wbr,
pluknet



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