On Tue, Oct 29, 2013 at 4:18 PM, Russ Allbery <ea...@eyrie.org> wrote:
> Jeffrey Walton <noloa...@gmail.com> writes:
>
>> -Wconversion should be included. That's because -1 > 1 after promotion:
>
>>     signed int i = -1;
>>     unsigned int j = 1;
>
>>     if(i > j)
>>         printf("-1 > 1 !!!\n");
>
>> I understand its going to be a pain point for those who don't pay
>> attention to details.
>
> -Wconversion produces (or at least produced; I've not rechecked recently)
> unfixable warnings for most network code due to macro expansion.  See:
>
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488884
>
> The pattern explained in that bug is still present in the current glibc
> headers.
Well, you can do one of three things. You can allow the defective code
to thrive, you can fix the defective code, or you can ban the
defective code and provide a replacement.

In my case, I choose to ban the defective code and replace it with
well written *and* well instrumented code because its dangerous in
practice. Its a security gate, and I don't have the time or energy to
devote to the l33t hackers feel the C programming language rules don't
apply to them. For example, bitops.h is banned from my code bases due
to its undefined behavior.

I'm not sure its a good idea to allow substandard code to thrive
because l33t hackers wrote it. I still remember Drepper's wisdom on
strlcat (and friends), which he called "horribly inefficient BSD crap"
[0]. He refused to add the safer string and memory functions of
ISO/IEC TR24731-1 to the runtime. Years later, his wisdom yielded
multiple buffer overflows in uPnP, which left millions of routers,
gateways, and other embedded devices vulnerable [1]. I'm still using
one of those unpacthed junk gateways because my ISP won't upgrade it
or replace it.

Jeff

[0] PATCH: safe string copy and concatenation [sic],
http://www.sourceware.org/ml/libc-alpha/2000-08/msg00053.html
[1] Portable SDK for UPnP Devices (libupnp) contains multiple buffer
overflows in SSDP, http://www.kb.cert.org/vuls/id/922681

_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Reply via email to