[PATCH] Fix bfd build with CVS glibc

[PATCH] Fix bfd build with CVS glibc

[Jakub Jelinek]

Hi!

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.

2007-08-16  Jakub Jelinek  <jakub@redhat.com>

	* opncls.c (bfd_openr_iovec): Surround open with parentheses.

--- bfd/opncls.c.jj	2007-08-01 09:11:48.000000000 -0400
+++ bfd/opncls.c	2007-08-16 06:23:39.000000000 -0400
@@ -545,7 +545,7 @@ bfd_openr_iovec (const char *filename, c
   nbfd->filename = filename;
   nbfd->direction = read_direction;
 
-  stream = open (nbfd, open_closure);
+  stream = (open) (nbfd, open_closure);
   if (stream == NULL)
     {
       _bfd_delete_bfd (nbfd);

	Jakub

Re: [PATCH] Fix bfd build with CVS glibc

[Maciej W. Rozycki]

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

Re: [PATCH] Fix bfd build with CVS glibc

[Alan Modra]

On Thu, Aug 16, 2007 at 12:58:00PM +0200, Jakub Jelinek wrote:
> 2007-08-16  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* opncls.c (bfd_openr_iovec): Surround open with parentheses.

I've already OK'd a patch to do this.  This is OK too.  Whoever
commits first wins.  :-)

-- 
Alan Modra
Australia Development Lab, IBM