Re: [PATCH] lib/autoconf/c.m4: fix NULL pointer dereference in _AC_LANG_IO_PROGRAM

[Eric Blake]

> > While I'm not opposed to your patch, I don't think that chasing the
> > windmill of making configure snippets warning-free is going to be
> > worth it, because in the end, it won't change the results of those
> > configure tests.
> 
> I do not understand what you mean by "chasing the windmill", and the
> top result on Google Search
> (https://iit.adelaide.edu.au/news/list/2021/04/29/chasing-the-windmill-what-is-wrong-with-the-us-approach-on-developing-country)
> seems to be about developing countries. Is this some cultural
> reference that non-English-speaking people are not supposed to
> understand? Could you please use expressions for which the meaning can
> be easily searched on the Internet?

I'm sorry if I was unclear, I did not mean for an idiom to get in the
way of understanding.

https://forum.wordreference.com/threads/dont-go-chasing-windmills.2539680/
is probably closest to my intent, a reference to Don Quixote's attempt
to chase (or fight) windmills - it may look fantastic, but is it
really accomplishing anything?  (And since the source for that
reference is from classic Spanish literature (Miguel Cervantes), not
English, I'm actually surprised that it now comes across as an English
idiom)

> 
> On the topic, I agree that "making configure snippets warning-free" is
> not a great objective, and is quite difficult because static code
> analyzer software tends to report many false positive issues. But here
> it is a real fix and I find it inappropriate that you reply with a
> message which translates to "you are doing something idiot, please
> stop this stupid thing, static analysis is worthless". In my opinion,
> I can carry patches on my own which help reduce the number of false
> positive issues reported by static analyzer tools (without involving
> any upstream discussion), but when I find a bug I prefer to report it
> and help upstream developers to fix it rather than keeping it for
> myself. This is why I submitted a patch and I believe such an approach
> is what makes free software possible, instead of calling the work of
> someone else "not worth it".

Email is absolutely the worst means for conveying emotion and intent,
because that was NOT my intent to put down your contribution.  In
fact, I even realized that before I hit send, since I added:

> 
> > But lest I sound too negative, thank you for reporting what you found,
> > and for providing a patch!

But I will apologize again for sounding unappreciative of your patch,
because that was not my goal.  You are right that submitting patches
you have is the best way for the project to move forward.

> >
> > > The information contained in this email and in any
> > > document enclosed is strictly confidential and is intended solely for the
> >
> > Legalese blurbs like these are unenforceable on a publically-archived
> > mailing list; you may want to consider using an alternative account
> > that does not append your employer's text on your mails to open source
> > lists.
> 
> Sorry about this. I posted the patch from my professional email and
> missed the fact that my employer added a few weeks ago a configuration
> to GMail which automatically adds this blurb, even to full-text emails
> sent to mailing lists.

Thanks!  That indeed makes it easier to reply to your mail without
worrying whether I'm getting in trouble with your employer.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org