This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix bfd build with CVS glibc

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]