[PATCH] shrink last_char_is function even more
explorer09 at gmail.com
Mon Jul 20 17:37:59 UTC 2020
On Monday, July 20, 2020, Tito <farmatito at tiscali.it> 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).
>> 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.
> 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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the busybox