[PATCH] shrink last_char_is function even more

Kang-Che Sung 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).
>>
>>  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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20200721/81471f04/attachment.html>


More information about the busybox mailing list