[m-rev.] for post-commit review: report unqualified types in .int files
Peter Wang
novalazy at gmail.com
Sun Oct 11 12:08:29 AEDT 2020
On Sat, 10 Oct 2020 19:00:47 +1100 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>
> 2020-10-10 18:45 GMT+11:00 "Dirk Ziegemeyer" <dirk at ziegemeyer.de>:
> > mercury_memory_handlers.c:64:6: error: "MR_HAVE_SIGINFO defined but don't know how to get it"
> > #error "MR_HAVE_SIGINFO defined but don't know how to get it"
> > ^
> > mercury_memory_handlers.c:83:6: error: "MR_HAVE_SIGINFO defined but don't know how to get it"
> > #error "MR_HAVE_SIGINFO defined but don't know how to get it"
> > ^
> > mercury_memory_handlers.c:270:41: error: use of undeclared identifier 'bus_handler'
> > MR_setup_signal(SIGBUS, (MR_Code *) bus_handler, MR_TRUE,
> > ^
> > mercury_memory_handlers.c:273:42: error: use of undeclared identifier 'segv_handler'
> > MR_setup_signal(SIGSEGV, (MR_Code *) segv_handler, MR_TRUE,
>
> It seems that mercury_memory_handlers.c expects MR_HAVE_SIGINFO to be set
> in a small set of circumstances, as indicated by the #ifs nested inside #ifdef MR_HAVE_SIGINFO,
> but configure.ac sets MR_HAVE_SIGINFO in more circumstances than that. It looks like
> mercury_memory_handlers.c was not updated when configure.ac was.
>
> Peter, you wrote most of the configure.ac lines that mention MR_HAVE_SIGINFO,
> and you also touched them most recently, so could you please have a look at this?
I only reformatted those lines two years ago.
I expect what's happening is this:
- sigaction should always be found, so MR_HAVE_SIGINFO is defined by
configure.ac line 1577
- sigcontext/sigcontext_struct seems to be some Linux specific thing,
so I don't think it ever would have been defined on MacOS.
(That code might never be used on any modern Linux either,
so could be deleted? Will need to confirm later.)
- MR_HAVE_SIGINFO_T is defined on line 1816 but the test that enables
it looks pretty complicated and may have broke with the MacOS update.
Peter
More information about the reviews
mailing list