Re: #import, #pragma once to be removed in 3.4

[Jonathan Lennox <lennox at cs dot columbia dot edu>]

Kai Henningsen writes:
> Maybe what we need is to have someone who is responsible for the language  
> definition. Or in other words, a project to create a definitive definition  
> for the language, on a level similar to, say, the ISO C standards

Such a specification is unlikely to resolve the #import problem, though. An
ISO-language spec would almost certainly have to declare the meaning of
#import to be implementation-defined, since, after all, the meaning of
#include is implementation-defined.

I think it's a perfectly reasonable solution, though, to say (even in the
absence of a formal Objective C spec) that it's implementation-defined when
two #import'ed files are "the same".  The FSF compiler can define it as
"same normalized absolute path" (using Neil's algorithm to resolve relative
paths in directory symlinks), and the Apple compiler can define it as "same
device and inode", and portability guides can tell people not to rely on
#import necessarily detecting symbolic or hard links as the same file.

(In fact, this definition of #import would allow the suggestion that someone
made, that it be a synonym for #include in FSF Objective C -- the
implementation definition of when two files are the same could be "never".
People would probably consider this to be poor QoI, though.)

For the PCH issue, would it be possible to store the modification time of
the precompiled header files -- the same field that's used by '#pragma GCC
dependency'?  If those don't match, the PCH can be rejected.  In fact, would
it be a good idea to give a PCH file an implicit '#pragma GCC dependency' on
every file that's been preprocessed?

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu