Re: #import future (summary and proposed solutions)

[Zack Weinberg <zack at codesourcery dot com>]

"Timothy J. Wood" <tjw@omnigroup.com> writes:

[...]
>    How do oponents of #import think we are supposed to write header
> guards??  Are we supposed to use this silly pattern?
>
> #ifndef _FILENAME_H
> #define _FILENAME_H
> ...
> #endif /* _FILENAME_H*/
>
>    What happens when you get two competing packages with the same
> file?

Yes you are.  If this pattern doesn't work you're already hosed,
because you have a conflict on the short name of the file itself.

>    Instead, as much vagueness as possible should be removed and any
> remaining issues stated clearly.  The main vague point that I see is
> the question of content identity vs. location identiy.  I'd argue that
> it's been strongly implied since the NEXTSTEP days that #import used
> location identity rather than some checksum approach.

Unfortunately it must be content identity, because otherwise you get
spurious failures when the preprocessor can't prove that two files are
the same, so it has to read them both.  And this is not a hypothetical
problem - I have seen it bite people in the wild.

I suspect you don't realize how easy it is to break a purely
location-based identity check.  Consider the not uncommon situation
where there is both a /usr/include/time.h and a
/usr/include/sys/time.h.  Suppose that neither of these has an #ifndef
wrapper, and suppose that /usr/include/sys/time.h contains, among
other things,

#import "../time.h"

Now a user program that contains

#import <sys/time.h>
#import <time.h>

Geoff's (re)implementation of #import, as I understand it, will fail
to discover that /usr/include/sys/../time.h and /usr/include/time.h
are in fact the same file, so it will be read twice - and since there
is nothing but the #import check to prevent the compiler from seeing
double declarations, the compiler will see double declarations.

zw