On Monday, July 20, 2020, Tito <[email protected]> wrote: > > > 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 ;-) >
Hi. Just my small opinion here. Coding defensively is not necessarily a wrong thing by itself. And I do write things defensively for my programming job. The key point is that coding defensively does not mean adding unnecessary, sanity checks for everything. That would hurt performance. When a function expects a non-null pointer argument from the caller (and you are sure that caller code is sane already), use GCC's nonnull attribute and assertions. That's what assert statements are for - conveying your code assumptions and do the sanity checks for debugging and only in the debug build. That would keep your "defensive" attitude without sacrificing any performance thing.
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
