On Wed, Oct 1, 2025 at 1:52 AM Grisha Levit <[email protected]> wrote:
>
> On Tue, Sep 30, 2025 at 10:00 PM Collin Funk <[email protected]> wrote:
> >
> > Chet Ramey <[email protected]> writes:
> >
> > >> You can probably just add a check add something like:
> > >> if (bytes < PTRDIFF_MAX)
> > >> {
> > >> errno = ENOMEM;
> > >> return NULL;
> > >> }
> > >> to silence it (although I haven't tested it).
> > >
> > > I hate adding code just to silence spurious warnings.
> >
> > I don't blame you. I should have mentioned that the example was more-so
> > an explanation of what the warning was about. The message is not too
> > helpful, in my opinion.
> >
> > It seems the OP is using special compiler options (which is a perfectly
> > reasonable way to hunt for bugs), since I do not see these warnings by
> > default with GCC 15 on Fedora.
>
> I believe this warning shows up only because gcc with -flto can notice
> this code path in shell_getc where realloc gets called with a size arg
> that is a constant larger than PTRDIFF_MAX:
>
> if (shell_input_line_size > (SIZE_MAX - 256))
> ...
> shell_input_line_size = SIZE_MAX;
> shell_input_line = xrealloc (shell_input_line, shell_input_line_size);
>
> If we are going to guard against theoretical overflow, we might as well
> use the more correct allocation size limit of PTRDIFF_MAX, which will
> silence this warning.
Sorry, just noticed that this is basically Martin's earlier message with
s/RSIZE_MAX/PTRDIFF_MAX/g.
Though the patches should have the same effect, the motivation for using
PTRDIFF_MAX is that according to [1]:
-Walloc-size-larger-than=‘PTRDIFF_MAX’ is enabled by default
[1]:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Walloc-size-larger-than_003d
