On Mon, 14 Jun 2021 at 18:03, Martin Sebor <mse...@gmail.com> wrote:
>
> On 6/14/21 6:17 AM, Jonathan Wakely via Gcc-patches wrote:
> >       PR c++/101052
> >
> > gcc/c-family/ChangeLog:
> >
> >       * known-headers.cc (get_stdlib_header_for_name): Add known
> >       headers for EXIT_FAILURE, EXIT_SUCCESS, abort, atexit, calloc,
> >       exit, and getenv.
> >
> > gcc/testsuite/ChangeLog:
> >
> >       * g++.dg/spellcheck-stdlib.C: Add checks for <cstdlib> names.
> >       * gcc.dg/spellcheck-stdlib.c: Likewise.
> >
> > There are no C tests for the functions because the C front-end doesn't
> > give fix-it hints for them, it complains about mismatched implicit
> > declarations. I assume this is why there were no existing tests for
> > malloc, free, etc.
> >
> > Tested powerpc64le-linux. OK for trunk?
>
> A while back I noticed some other symbol wasn't giving a nice hint.
> I think it was one of the <stdint.h> macros that I can never remember
> if it's in <inttypes.h> or <limits.h>.  So decided to add them all,
> and while I was there, I noticed that the function does a linear
> search through the array.  That seems suboptimal so I started
> optimizing it and never finished the work.

Yes, I noticed that. We only search the array after compilation fails,
so performance doesn't really matter.

>
> So I'm wondering if you stopped at the seven above for the same
> reason or some other?

I lost the motivation to add the rest of <stdlib.h> when testing it
for C turned out to be difficult due to C allowing implicit
declarations.


>
> FWIW, I think the symbols that are hardcoded there now are some of
> the most obvious ones.  The ones that are harder to remember tend
> to be missing.  (E.g., I'd probably include <wchar.h> for wcstombs
> and would have to look it up if I got an error.  YMMV of course.)

Yes, that's why I wanted to add aligned_alloc, at_quick_exit and
quick_exit, in a new c11_cxx11_hints array. They're maybe less "well
known" than exit and malloc.

> This is not an objection to adding just a handful of new names, just
> a comment on the general state of incompleteness and the inefficient
> data structure in case that matters.  If we don't care enough about
> the inefficiency to avoid completing the list then I'd suggest to
> add all the missing <stdlib.h> names, not just the seven above.

Reply via email to