[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [1003.1(2008)/Issue 7 0000305]: Allow RE handling to reject suspicio
From: |
Eric Blake |
Subject: |
Re: [1003.1(2008)/Issue 7 0000305]: Allow RE handling to reject suspicious uses |
Date: |
Thu, 02 Sep 2010 08:36:38 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2 |
On 09/02/2010 02:38 AM, Geoff Clare wrote:
I would support a more restrictive variant of the proposed change,
along the lines you suggest where only duplicated first and last
characters are considered, although I would go slightly further
and say there has to be at least one character between them
(so that [::], [..] and [==] are not diagnosed).
Sounds fair enough. I guess I can try to get a new proposed wording in
place before today's Austin Group meeting.
If we want to allow a warning message with non-error exit status,
then additional changes are needed as some (possibly all; I checked
awk, grep, ed, ex and sed) of the affected utilities are only allowed
to write to standard error when their exit status indicates an error.
>
See XCU 1.4 under STDERR:
Default Behavior: When this section is listed as "The standard
error shall be used only for diagnostic messages.", it means that,
unless otherwise stated, the diagnostic messages shall be sent to
the standard error only when the exit status indicates that an
error occurred and the utility is used as described by this volume
of POSIX.1-2008.
It could be argued that stating "behavior is unspecified" would
override this general rule, but I don't think it would be sufficiently
clear.
On the contrary, I think it is already sufficiently clear (albiet a bit
indirect): my understanding of "behavior is unspecified" is that any
application that passes a problematic RE is already outside of the
confines of the standard, so the standard rule on stderr output
mandating non-zero exit status no longer applies. Various GNU
applications have already exploited this aspect of the standard to print
warning messages when encountering input that is left unspecified by the
standard.
However, in the case of GNU grep, it is not an issue - the intention is
to exit with status 2 after printing a hard error message, rather than
printing a warning message and proceeding onwards with a successful exit
status.
Also, the aardvark only talks about utilities. How would we handle
this for regcomp()?
That's a good point indeed - the aardvark probably needs to be broadened
to allow an implementation extension to <regex.h>, such that regcomp()
can fail with an implementation-extension error if that is how the
implementation desires to handle the unspecified behavior associated
with that problematic regular expression.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [1003.1(2008)/Issue 7 0000305]: Allow RE handling to reject suspicious uses,
Eric Blake <=