[PATCH] shrink last_char_is function even more

Tito farmatito at tiscali.it
Mon Jul 20 11:58:11 UTC 2020



On 7/20/20 9:22 AM, Laurent Bercot wrote:
>> The param should be marked with the nonnull attribute, just like the
>> libc string functions. Then the compiler will warn you if you try to
>> pass NULL (may need higher optimization, warning levels, or the
>> analyzer mode in complex cases).
> 
>  Indeed.
> 
>  A function that takes a pointer that *cannot* be NULL, and a function
> that takes a pointer that *may* be NULL, are not the same thing at all.
>  This is one of the main reasons while a lot of people find C pointers
> difficult: a pointer can be used for two very different things, namely
> unconditionally representing an object (passing it by address), or
> representing the *possibility* of an object. In ocaml, the former would
> would be typed "'a ref", and the latter "'a ref option", and those are
> *not the same type*.
> 
>  When writing and using a function that takes pointers, a C programmer
> should always be very aware of the kind of pointer the function expects.
> It is a programming error to pass NULL to a function expecting a pointer
> that cannot be NULL, and that error should be caught as early as
> possible. The nonnull attribute helps detect it at compile time. And
> at run time, if the function gets NULL, it should crash, as loudly as
> possible, in order for the bug to be fixed.

Hi,

while I agree with you in theory, the reality looks different to 
me, being an external observer, because with increasing code base,
increasing complexity, increasing number of people messing with
the code, increasing time pressure the result is a flood of CVE's
and updates and patch Tuesdays, etc..
So a question arises to me, aren't all this programmers able to do their job or
is this the result of sloppy programming or a deficiency of defensive
programming taking into account that humans for all the aforementioned
reasons will certainly do mistakes in a unpredictable but very effective way?
I for myself decided for being defensive and this until today
payed off for my little personal codebase.
I save you from showing examples of my defensive coding
that I'm sure would horrify most of the list members ;-)

Ciao,
Tito

>  Checking for NULL "just in case" is defensive programming, which is
> very bad. It means the programmer does not know exactly what the
> function contracts are: it would be better named "sloppy programming".
> Please don't do this.
> 
> -- 
>  Laurent


More information about the busybox mailing list