Dear all,
error recovery on arithmetic errors during simplification has bugged
me for a long time, especially since the occurence of ICEs depended
on whether -frange-check is specified or not, whether array ctors
were involved, etc.
I've now come up with the attached patch that classifies the ari
On 5 March 2024 04:15:12 CET, Jerry D wrote:
>
>Attached is the revised patch using the already available string_len_trim
>function.
>
>This hunk is only executed if a user has not passed an iostat or iomsg
>variable in the parent I/O statement and an error is triggered which
>terminates execu
Hi Jerry,
I think there is the risk of buffer overrun in the following places:
+ char message[IOMSG_LEN];
+ child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg)
+ 1;
free_line (dtp);
snprintf (message, child_iomsg_len, child_iomsg);
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
On 3/5/24 22:37, Harald Anlauf wrote:
Hi Jerry,
I think there is the risk of buffer overrun in the following places:
+ char message[IOMSG_LEN];
On 3/5/24 1:51 PM, Harald Anlauf wrote:
Hi Jerry,
on further thought, do we sanitize 'child_iomsg'?
We pass it to snprintf as format.
Wouldn't a strncpy be sufficient?
Harald
Just to be safe I will bump char message[IOMSG_LEN] to char
message[IOMSG_LEN + 1]
This is like a C string vs a
On Tue, Mar 05, 2024 at 08:06:10PM -0800, Jerry D wrote:
> On 3/5/24 1:51 PM, Harald Anlauf wrote:
> > Hi Jerry,
> >
> > on further thought, do we sanitize 'child_iomsg'?
> > We pass it to snprintf as format.
> >
> > Wouldn't a strncpy be sufficient?
> >
> > Harald
> >
> >
>
> Just to be safe
