[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231201155240.GB4163@brightrain.aerifal.cx>
Date: Fri, 1 Dec 2023 10:52:40 -0500
From: Rich Felker <dalias@...c.org>
To: Anuraag Agrawal <anuraaga@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Re: Large overflow in __intscan ignored
On Fri, Dec 01, 2023 at 02:14:03PM +0900, Anuraag Agrawal wrote:
> Oops, sorry I should have mentioned, the inputs I am working with that do
> not set errno are
>
> 999999999999999999999
> 1000000000000000000000
> 4790999999999999999999999999999999999999999999999999999999999999999999999999999999999999
> 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
>
> For context, they come from test cases in libpg_query
>
> https://github.com/pganalyze/libpg_query/blob/15-latest/test/scan_tests.c#L30
>
> On Fri, Dec 1, 2023 at 2:08 PM Anuraag Agrawal <anuraaga@...il.com> wrote:
>
> > Currently, __intscan, used by functions like strtol, does not seem to
> > check for overflow during multiplication.
> >
> > https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n69
> >
> > It at the end checks against the limit, e.g. the size of a long
> >
> > https://git.musl-libc.org/cgit/musl/tree/src/internal/intscan.c#n90
> >
> > However, if the value overflows and ends up in the range of the limit,
> > errno will not be set. It seems that each multiplication operation needs to
> > be checking for overflow and return errno if it ever happens.
Can you clarify whether you are reporting a bug in musl or trying to
reuse this code and possibly making breaking changes to your copy? I
cannot reproduce any problem with your test cases. They all correctly
report ERANGE. Checked for strtol, strtoll, and strtoull.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
