On 3/6/24 9:13 AM, Harald Anlauf wrote:
Hi Jerry,
can you please replace the user message in e.g. your new testcase
pr105456-wf.f90 by say:
piomsg="The users message containing % and %% and %s and other stuff"
This behaves as expected with Intel, but dies horribly with gfortran
after your
Hi Jerry,
can you please replace the user message in e.g. your new testcase
pr105456-wf.f90 by say:
piomsg="The users message containing % and %% and %s and other stuff"
This behaves as expected with Intel, but dies horribly with gfortran
after your patch!
Cheers,
Harald
On 3/6/24 05:06,
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
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
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
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);
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
On 3/1/24 11:24 AM, rep.dot@gmail.com wrote:
Hi Jerry and Steve,
On 29 February 2024 19:28:19 CET, Jerry D wrote:
On 2/29/24 10:13 AM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
And, just for my own
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
> On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
>
> > And, just for my own education, the length limitation of iomsg to 255
> > chars is not backed by the standard AFAICS, right? It's just our
> > STRERR_MAXSZ?
>
> Yes, its what we
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D wrote:
The attached patch adds the error checks similar to the first patch
previously committed.
I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
consolidated this to one define in
On Wed, 28 Feb 2024 21:29:06 -0800
Jerry D wrote:
> The attached patch adds the error checks similar to the first patch
> previously committed.
>
> I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
> consolidated this to one define in io.h. This is just cleanup stuff.
>
> I
The attached patch adds the error checks similar to the first patch
previously committed.
I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
consolidated this to one define in io.h. This is just cleanup stuff.
I have added test cases for each of the places where UDTIO is done
12 matches
Mail list logo
