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

[Eric Blake]

[adding bug-grep, for any additional feedback from others involved in 
raising this issue in the first place - this is feedback to 
http://austingroupbugs.net/view.php?id=305]

On 09/01/2010 04:34 PM, Glenn Fowler wrote:
> just to you to verify my understanding:
>
> so the forms in question are the following outside of [ ... ]:
>
>         [:<name>:]
>         [=<collating-element>=]
>         [.<collating-element>.]

Yes, those are the only three forms where current GNU grep would like to 
warn at the moment.  An infrastructure was proposed that would allow 
other warnings could be added in the future for other questionable RE, 
but we couldn't think of any at the moment (and any such future warnings 
would also have to undergo the scrutiny of whether POSIX allows such a 
warning).

> and the proposal is to allow an implementation to reject the forms
>
> I admit getting bit by this while working on grep and tr at the same time
> (tr allows ``tr '[:lower:]' '[:upper:]')

Which is why GNU grep added the warning in the first place; the question 
at hand on the GNU list is whether the warning must be inhibited by 
POSIXLY_CORRECT, or whether POSIX can condone the warning as a useful 
QoI feature.

> how about taking the extra step of specifying the behavior of the
> above forms:
>
>         RE                              INTERPRET AS
>         [:<name>:]                        [[:<name>:]]
>         [=<collating-element>=]           [[=<collating-element>=]]
>         [.<collating-element>.]           [[.<collating-element>.]]

Possible, but requiring a particular interpretation different from the 
current one would render existing implementations non-compliant.

> I don't remember the details of the original discussions leading
> to [...[:<name>:]...] -- how controversial was it since it potentailly
> changes the semantics of previously valid REs?  if it wasn't
> earth-shattering maybe specifying the probably-meant-this behavior
> would be possible
>
> if not, then allowing diagnostics would be ok with me

In my mind, the 'unspecified behavior' route is the best - it allows an 
implementer to choose between at least three different behaviors that I 
would consider reasonable: interpret as matching only the characters in 
[<name>:] so that existing implementations need not change; interpret as 
[[:<name>:]] to match tr; or issue a warning/error to alert users to the 
non-portability aspect.

> would this mean an implementation could add a new<regex.h>  error code?

It may indeed be worthwhile to reword the bug 305 proposal to allow an 
implementation to extend <regex.h> in that manner, although it is not 
strictly necessary (GNU grep's warning was implemented without the need 
of a new <regex.h> error code).

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org