Re: [1003.1(2008)/Issue 7 0000305]: Allow RE handling to reject suspicious uses

[Eric Blake]

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