------- Comment #10 from pgut001 at cs dot auckland dot ac dot nz 2008-06-11 03:47 ------- >13. Unlike for C9X, the consensus at the London meeting was that there should >be no invention, without exception. Only those features that have a history >and are in common use by a commercial implementation should be considered. >Also there must be care to standardize these features in a way that would >make the Standard and the commercial implementation compatible.
Well they've done exactly that, it's perfectly compatible with VC++ (via PREfast), which is a widely-used commercial implementation :-). >Do you have a reference to the incompatible proposal? I sent N1259 a while >back warning about incompatibilities in syntax; perhaps a paper is needed on >incompatible semantics as well. I'm using N1273, which seems to be the only published statement on the use of attributes. For stdc_nonnull it describes the proposed semantics as: To be discussed[[the implementation may/it is implementation defined add assertions to ensure the runtime values of the variables are not null pointers] OTOH the gcc interpretation of this seems to be: To be discussed[[the implementation may/it is implementation defined *remove* assertions that ensure the runtime values of the variables are not null pointers] If the current gcc behaviour is regarded as correct and appropriate then maybe the docs need to be updated (which is why I originally reported this as a doc. bug, I wasn't sure which of the two was definitive). Currently the docs say something to the effect of: The compiler WILL issue warnings and MAY change its code generation when it sees this attribute. when in fact what it really does is: The compiler WILL change its code generation and MAY issue warnings when it sees this attribute. So the proposed change would be to substitute, in place of the current ... causes the compiler to check that, in calls to my_memcpy, arguments dest and src are non-null. If the compiler determines that a null pointer is passed in an argument slot marked as non-null, and the -Wnonnull option is enabled, a warning is issued. The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. the new text: ... causes the compiler to make optimizations based on the knowledge that certain function arguments will not be null. The compiler may also choose to check that, in calls to my_memcpy, arguments dest and src are non-null. If the compiler determines that a null pointer is passed in an argument slot marked as non-null, and the -Wnonnull option is enabled, a warning is issued. This more accurately reflects the actual behaviour of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36166
