On 10/07/2013 10:53 AM, Glenn Golden wrote: > Unfortunately, the standard seems to offer no insight as to what is meant or > intended by "cannot use". One interpretation, which seems non-tortuous to me, > is as follows: > > * Conforming applications must not accept x > P as input.
Not true. Rather, the intent of POSIX is that if an application is presented x > P as input, then the application is no longer bound by the rules of POSIX, and undefined behavior will occur. That is, rather than make your application worry about the diagnosis of x > P, you can instead transfer the blame to the user that is passing you bogus input. Remember, POSIX also says that strlen(NULL) is undefined behavior. In some implementations, it succeeds (generally with the value 0); in others it fails by causing SIGSEGV. But the whole point is that it is undefined - the burden is on the user to not pass invalid input in the first place, and not on libc to react in any particular manner to that bad input. The burden of strictly conforming is on the caller to not provide bad input in the first place, not on what the receiver must (or must not) do with input that is out of spec. > > Or stated in a more practically actionable way: > > * If presented with an RE x > P as input, a conforming application must > diagnose it as fatal (i.e., declare it in error and refuse to continue.) That is one possible action to take on undefined behavior, and might even be a desirable behavior, but it is NOT required behavior, and does not happen to be the current behavior of grep unless someone writes a patch. Remember, 'sed --posix' is an extension to POSIX where GNU sed tries hard to diagnose extension inputs, and we would not be opposed to such a patch for grep if it is easy to maintain; but I am also personally unlikely to write such a patch. If you still worry about what POSIX intends or not, it is probably better to ask the actual POSIX list (<austin-grou...@opengroup.org>), as they would actually be able to do something about it. This list is probably not the most effective place to argue about what POSIX intended. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
