Hi,
On 4/20/23 20:46, наб wrote:
> Hi!
>
> On Thu, Apr 20, 2023 at 07:23:39PM +0200, Alejandro Colomar wrote:
>> On 4/20/23 17:35, наб wrote:
>>> +.I errcode
>>> +must be the latest error returned from an operation on
>>> +.IR preg .
>>> +If
>>> +.I preg
>>> +is a null pointer\(emthe latest error.
>> I don't read that from the POSIX spec.
> Whereas that's precisely where I got it from.
Here's the quote I think is the most relevant (you also quoted it
below):
If preg is a null pointer, but errcode is a value returned by a
previous call to regexec() or regcomp(), the regerror() still
generates an error string corresponding to the value of er‐
rcode, but it might not be as detailed under some implementa‐
tions.
>
>> If preg is NULL, then I think any
>> error returned by a call to one of these APIs would be valid.
> That's unspecified.
I don't think so. POSIX says a "previous call". It doesn't say the
"latest" or "immediately preceeding" or similar wording. Don't you
understand the same from that paragraph?
>
>> In fact,
>> since these functions are MT-Safe, they can't store any state,
> Probably. OTOH, musl raw-dogs mbtowc() in regexec(), so.
> (I'm pretty sure it's by accident since they do have a mbstate_t
> and juggle it a lot, but it's never actually used.)
>
>> which leads
>> me to think that they can't really distinguish between the latest error,
>> and an error returned at a random point in the past, or even the result of
>> csrand_interval(x, y)[1] with appropriate x and y.
> Again, probably. But (line numbers from Issue 8 Draft 2.1):
> 57517 The regerror( ) function provides a mapping from error codes returned by regcomp( ) and
> 57518 regexec( ) to unspecified printable strings. It generates a string corresponding to the value of the
> 57519 errcode argument, which the application shall ensure is the last non-zero value returned by
> 57520 regcomp( ) or regexec( ) with the given value of preg. If errcode is not such a value, the content of
> 57521 the generated string is unspecified.
>
> 57522 If preg is a null pointer, but errcode is a value returned by a previous call to regexec( ) or regcomp( ),
> 57523 the regerror( ) still generates an error string corresponding to the value of errcode, but it might not
> 57524 be as detailed under some implementations.
>
> 57525 If the errbuf_size argument is not 0, regerror( ) shall place the generated string into the buffer of
> 57526 size errbuf_size bytes pointed to by errbuf. If the string (including the terminating null) cannot fit
> 57527 in the buffer, regerror( ) shall truncate the string and null-terminate the result.
>
> 57528 If errbuf_size is 0, regerror( ) shall ignore the errbuf argument, and return the size of the buffer
> 57529 needed to hold the generated string.
>
> In these difficult times I tend to turn to what implementations do:
> NetBSD, musl, illumos, and glibc, if you subtract REG_ATOI and REG_ITOA,
> all essentially return lsearch(errors, errcode)->description
> + all sans NetBSD localise it.
> None of them even use preg.
>
> So yeah, I'll axe that.
>
>
> And split out regfree() from this patch because I missed it.
Thanks,
Alex
>
>
> Best,
> наб
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
