Re: [RFC/PATCH v1 0/4] compat/obstack: update from upstream
- From
SZEDER Gábor <szeder.dev@gmail.com>
- Date
- Jun 17, 2019, 18:36 UTC
- Message-ID
- <20190617183628.GJ31952@szeder.dev>
- In-Reply-To
- <bd955bb3-626e-345d-550e-562027c2f7e6@ramsayjones.plus.com>
On Fri, Jun 14, 2019 at 09:30:20PM +0100, Ramsay Jones wrote:
Show 28 quoted lines
>
>
> 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:Oh, indeed. 3254310863 removed that "__attribute__ ((noreturn))" from the function's definition, but nowadays upstream writes that as "static _Noreturn void print_and_abort (void)", and I didn't realize that this _Noreturn is the same thing.
Show 9 quoted lines
> $ 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
Heh :)
Anyway, I won't do anything for the time being, in the hope that we can get on board with removing kwset/obstack...