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