On 3/1/24 11:24 AM, rep.dot.nop@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 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 have had for a long lone time. Once you throw an error >>>> things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len >>>> to 256. Nothing magic about it. >>>> >>> >>> There is no restriction on the length for the iomsg-variable >>> that receives the generated error message. In fact, if the >>> iomsg-variable has a deferred-length type parameter, then >>> (re)-allocation to the exact length is expected. >>> >>> F2023 >>> >>> 12.11.6 IOMSG= specifier >>> >>> If an error, end-of-file, or end-of-record condition occurs during >>> execution of an input/output statement, iomsg-variable is assigned >>> an explanatory message, as if by intrinsic assignment. If no such >>> condition occurs, the definition status and value of iomsg-variable >>> are unchanged. >>> character(len=23) emsg >>> read(fd,*,iomsg=emsg) >>> >>> Here, the generated iomsg is either truncated to a length of 23 >>> or padded with blanks to a length of 23. >>> >>> character(len=:), allocatable :: emsg >>> read(fd,*,iomsg=emsg) >>> >>> Here, emsg should have the length of whatever error message was >>> generated. >>> HTH >>> >> >> Well, currently, if someone uses a larger string than 256 we are going to chop it off. >> >> Do we want to process this differently now? > > Yes. There is some odd hunk about discrepancy of passed len and actual len afterwards in 22-007-r1, IIRC. Didn't look closely though. > --- snip --- 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 execution of the program. In this case, the iomsg string is provided in the usual error message in a "processor defined" way. (F2023): 12.6.4.8.3 Executing defined input/output data transfers --- 11 If the iostat argument of the defined input/output procedure has a nonzero value when that procedure returns, and the processor therefore terminates execution of the program as described in 12.11, the processor shall make the value of the iomsg argument available in a processor-dependent manner. --- OK for trunk? Regards, Jerry