On 14/06/2019 11:00, SZEDER Gábor wrote:
> Update 'compat/obstack.{c,h}' from upstream, because they already use
> 'size_t' instead of 'long' in places that might eventually end up as
> an argument to malloc(), which might solve build errors with GCC 8 on
> Windows.
>
> The first patch just imports from upstream and doesn't modify anything
> at all, and, consequently, it can't be compiled because of a screenful
> or two of errors. This is bad for future bisects, of course.
>
> OTOH, adding all the necessary build fixes right away makes review
> harder...
>
> I'm not sure how to deal with this situation, so here is a series with
> the fixes in separate patches for review, for now. If there's an
> agreement that this is the direction to take, then I'll squash in the
> fixes in the first patch and touch up the resulting commit message.
>
>
> Ramsay, could you please run sparse on top of these patch series to
> make sure that I caught and converted all "0 instead of NULL" usages
> in the last patch? Thanks.
I applied your patches to current master (@0aae918dd9) and, since
you dropped the final hunk of commit 3254310863 ("obstack.c: Fix
some sparse warnings", 2011-09-11), sparse complains, thus:
$ diff sp-out sp-out1
27a28,30
> compat/obstack.c:331:5: warning: incorrect type in initializer (different modifiers)
> compat/obstack.c:331:5: expected void ( *[addressable] [toplevel] obstack_alloc_failed_handler )( ... )
> compat/obstack.c:331:5: got void ( [noreturn] * )( ... )
$
So, yes you did catch all "using plain integer as NULL pointer"
warnings! :-D
Thanks.
ATB,
Ramsay Jones
