From: Adrian Bunk <bunk@stusta.de>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembeded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-oe][PATCH] libwebsockets: Fix the build with -Os
Date: Fri, 30 Aug 2019 08:13:17 +0300 [thread overview]
Message-ID: <20190830051317.GF24691@localhost> (raw)
In-Reply-To: <CAMKF1srqhNCYgMHkumXFda=ZLLfMOJB5ZhZJtMi00SpL5GTRYw@mail.gmail.com>
On Thu, Aug 29, 2019 at 03:09:17PM -0700, Khem Raj wrote:
> On Thu, Aug 29, 2019 at 2:23 PM Adrian Bunk <bunk@stusta.de> wrote:
> > On Thu, Aug 29, 2019 at 01:51:05PM -0700, Khem Raj wrote:
>...
> > > and better still with a patch.
> >
> > But please do not add such patches to OE.
> >
> > Patches from people who don't know the code well are often quite buggy,
> > and fixing warnings then tends to add more bugs than it fixes.
> >
> > Google "Debian OpenSSL disaster" for how the Debian maintainer "fixing"
> > a Valgrind warning in the Debian OpenSSL package made private keys used
> > for ssh authentication in Debian/Ubuntu predictable (AKA everyone on the
> > internet could log into the affected machines).
>
> right I remember that, but then I also know first-hand cases where the
> compiler was telling you all the way and it was
> ignored which ended up in field bugs, so there is no right answer.
>...
That's a lesson for upstream, not so much for a distribution.
The worst case is when people are just doing whatever is the fastest
code "fix" to silence a warning/error.
When the compiler is telling that the C library does not support
FNM_EXTMATCH, then ignoring the error with
#define FNM_EXTMATCH 0
can turn it into a field bug.
Ignoring the compile error when the C library does not support qsort_r
by using qsort instead can create exactly the runtime race conditions
qsort_r is designed to avoid.
Finding correct solutions can be hard and time-consuming,
especially when the person doing the change does not know
the code in question well.
But few correct fixes are better than many quick fixes that might
introduce more bugs than they fix.
And there is also a blame game involved:
If upstream software contains bugs, the blame goes to upstream.
If distribution patches introduce bugs, the blame goes to the
distribution.
Heartbleed was even worse than the above mentioned bug, but noone
could blame Debian for it.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
prev parent reply other threads:[~2019-08-30 5:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 10:39 [meta-oe][PATCH] libwebsockets: Fix the build with -Os Adrian Bunk
2019-08-29 18:46 ` Khem Raj
2019-08-29 19:14 ` Adrian Bunk
2019-08-29 19:54 ` Khem Raj
2019-08-29 20:25 ` Adrian Bunk
2019-08-29 20:51 ` Khem Raj
2019-08-29 21:23 ` Adrian Bunk
2019-08-29 22:09 ` Khem Raj
2019-08-30 5:13 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190830051317.GF24691@localhost \
--to=bunk@stusta.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.