This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: #import future (summary and proposed solutions)
On 27-Jan-2003, Nicola Pero <nicola@brainstorm.co.uk> wrote:
> [someone wrote:]
> > All that should be necessary to support the intent of #import, is to
> > reasonably inhibit the inclusion of a uniquely named file multiple times,
> > under reasonably typical conditions (i.e. inhibit the multiple inclusion
> > of files which resolve to the same absolute path and name, where it's the
> > responsibility of the author of the build environment to establish such
> > conditions, if #import is desired to behave as expected).
>
> I guess your `reasonably typical conditions' would be something like `all
> headers must be on the same linux filesystem, and you must not be using
> anything "complex" [such as links], else GCC won't be guaranteed to be
> able to compile your (correct) ObjC source code' ?
No, more like
`headers can be on different file systems; but you must
not be referring to the same storage via different paths,
else GCC won't be guaranteed to be able to compile your
(non-portable) ObjC source code'.
Claiming that Objective-C code which refers to the same storage by
different paths is "correct" even if it assumes that these different
paths will be treated as the same file is IMHO reading more into the
language specification than the specification actually says.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.