Input on PRs 99/100

Andrew Josey <[email protected]> Fri, 23 Sep 2005 13:48:43 +0100
Newsgroups gmane.linux.lsb.test-suite
Message-ID <[email protected]>
All
I took the action to ask my engineers about problem reports 99 and 100

 http://www.opengroup.org:8000/lsb/publicpr/PRView?PR=0099
 http://www.opengroup.org:8000/lsb/publicpr/PRView?PR=0100

This is their input:

I don't think it should be allowed.  The relevant part of the
description of the mprotect() ENOMEM error in the standard is
"Addresses in the range [addr,addr+len) are invalid for the address
space of a process", so clearly the check for (this type of) ENOMEM
condition has to be done against the address space of the calling
process.  Since 32-bit and 64-bit processes have different address
spaces the check needs to be done differently for 32-bit and 64-bit
processes in order for ENOMEM to be correctly detected in both cases.

Even if it could be argued that detecting ENOMEM should not be
required in this case, the only allowed alternative behaviours are
for mprotect() to succeed or to return a different error indication.  
It should not hang, as the application has not done anything that
the standard says is undefined behaviour.

regards
Andrew