Re: 1.5.8 build failure on Solaris 8
Oswald Buddenhagen writes:
> On Fri, Mar 04, 2005 at 04:07:32PM +0000, Aaron Crane wrote:
> > Oswald Buddenhagen writes:
> > > #include <unistd.h>
> > > #define posix_lseek(a,b,c) lseek(a,b,c)
> > > #ifdef lseek
> > > # undef lseek
> > > #endif
> >
> > Given the '#undef lseek', defining another name isn't necessary.
>
> but you want to use lseek (or any of the other wrapped functions),
> otherwise you wouldn't have included the header in the first place.
But, as long as you've done
#include <unistd.h>
you've got a declaration in scope for lseek(). Implementations are
given the latitude to define a macro that shadows the real function, but
you're still guaranteed that the real function exists, and that it's
been declared appropriately.
> > (And I'd even argue that it's slightly harmful -- you're stepping on
> > yet more parts of the global namespace, but you still can't use
> > "open" as a name with external linkage.)
>
> nobody wants to create a global symbol with that name. we are talking
> about structure members, which have no linker symbol associated with
> them at all.
It's the posix_lseek name that steps on the global namespace more than
is necessary. If you include <unistd.h>, then, by definition, the name
lseek has been used in the global namespace.
> > > open() is a nightmare by itself, because it is a varargs function
> >
> > As long as you're not trying to define a macro that hides the global
> > open() name (and as long as there's a declaration in scope for it
> > when you call it) that shouldn't cause any problems.
>
> it is a problem. either the header assumes the preprocessor eats some
> type of varargs macros, in which case it will create a macro with
> parameters
That's the implementation's business, not yours (unless you're trying to
write a macro that wraps open(), as I said). The standard says that you
get a real function named open() with the appropriate prototype; and
that, in any particular implementation, this may be shadowed by a macro
with exactly the same effect. How the implementation accomplishes that
is nothing to do with the programmer. For example, there's no guarantee
that standard headers even exist as ordinary files; the standard merely
says that when a program contains (say)
#include <stdio.h>
the appropriate declarations and definitions are "made available" to the
program.
I think we may be talking at cross purposes here.
--
Aaron Crane