Hi Junio,

On Mon, 17 Jun 2019, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 14 Jun 2019, Junio C Hamano wrote:
> >
> >> * js/gcc-8-and-9 (2019-06-13) 4 commits
> >>  - config: avoid calling `labs()` on too-large data type
> >>  - winansi: simplify loading the GetCurrentConsoleFontEx() function
> >>  - kwset: allow building with GCC 8
> >>  - poll (mingw): allow compiling with GCC 8 and DEVELOPER=1
> >>
> >>  Code clean-up for new compilers.
> >>
> >>  The 'kwset' one may want to be discussed a bit longer.  Perhaps
> >>  merge the other three earlier to 'next' and then to 'master'
> >>  separately?
> >
> > Or just take the kwset one with an adjusted commit message because it may
> > turn out that the kwset update will be blocked for a while because of
> > licensing issues?
>
> Sorry, but I do not understand why you'd want to "take" one that you
> suspect may be blocked for a while.  I'd rather see us unblock the
> other ones that are unproblematic, without taking them hostage,
> which was what I meant.

My apologies for causing confusion.

What I *tried* to suggest is to take my minimal `kwset: allow building
with GCC 8` together with the other three, as it fixes the build. Without
it, the build is not fixed under `DEVELOPER=1`, it is still broken.

This would prevent me from upgrading GCC in Git for Windows' SDK to GCC v8
or v9, as that SDK is used to run all the CI builds.

Sure, having this small wrapper around `xmalloc()` would be a less elegant
solution than the alternative (i.e. synchronize our `kwset` with
upstream). But that alternative will take substantially longer to
stabilize, and that would block the GCC upgrade substantially longer.

And I am quite confident that Gábor (or is it Szeder?) will be very able
to rebase their changes on top of that small compile fix.

That's all I meant to say.

Ciao,
Dscho