This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Fix bfd build with CVS glibc
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 16 Aug 2007 14:45:44 +0100 (BST)
- Subject: Re: [PATCH] Fix bfd build with CVS glibc
- References: <20070816105800.GB2279@sunsite.mff.cuni.cz>
On Thu, 16 Aug 2007, Jakub Jelinek wrote:
> open in CVS glibc with -D_FORTIFY_SOURCE{,=2} is implemented as
> a function-like macro so that it can check for invalid open uses
> like open ("foo", O_CREAT|O_RDWR); or
> open ("foo", flags); where flags is not known at compile time,
> but at runtime contains O_CREAT bit set.
> This is not violating POSIX, as POSIX permits standard functions
> to be implemented as function-like macros.
> opncls.c includes <fcntl.h>, so open can be implemented as function-like
> macro and is in the glibc case.
> The following spot in bfd_openr_iovec doesn't call open function though,
> but calls a function pointer open passed as parameter to the function.
> The following prevents it being expanded as function-like macro, ok for
> trunk and 2.18 branch?
>
> Alternative fix would be (also standard conforming) #undef open after
> including the headers, but that would mean the real open(1) calls
> in the file are not checked.
I think the most reasonable fix would actually be renaming parameters
(i.e. "pread" and "close" as well) so that they do not clash with the
global name space. Given your note referring to POSIX it should be
considered unsafe and unportable to shadow standard functions with local
definitions.
Maciej