Re: PATCH: Avoid accidentally opening files for write

[Nick Clifton <nickc at redhat dot com>]

Hi Mark,

> Tested on x86_64-unknown-linux-gnu.  OK to apply?

Have you tested this patch in both POSIX and non-POSIX build 
environments ?  Given your comments with the original posting I would 
assume so, but it would be nice to have that confirmed.  Also with a 
patch to a generic part of BFD it would be good if you could also test 
with a --enable-targets=all build, just to make sure.

> 2005-06-06  Mark Mitchell  <mark@codesourcery.com>
>
> 	* opncls.c (bfd_fopen): New API.
> 	(bfd_openr): Use it.
> 	(bfd_fdopenr): Likewise.
> 	* bfd-in2.h: Regenerated.

The bfd part of your patch is approved.

I do have one other concern however:

>   SYNOPSIS
> ! 	bfd *bfd_fopen (const char *filename, const char *target,
> !                         const char *mode, int fd);
>   
>   DESCRIPTION
> ! 	Open the file @var{filename} with the target @var{target}.
> ! 	Return a pointer to the created BFD.  If @var{fd} is not -1,
> ! 	then <<fdopen>> is used to open the file; otherwise, <<fopen>>
> ! 	is used.  @var{mode} is passed directly to <<fopen>> or
> ! 	<<fdopen>>. 
...
> !   if (strchr (mode, '+'))
> !     nbfd->direction = both_direction;
> !   else if (strchr (mode, 'r'))
> !     nbfd->direction = read_direction;
> !   else
> !     nbfd->direction = write_direction;

This assumes that the contents of 'mode' are well defined.  Is this the 
case for non-POSIX environments ?  For example can we be sure that the 
character 'R' is never used to indicate read-only status, or that an OS 
might allow a file created with just "a" to have the newly-written-to 
parts read back, effectively making "a" a read-and-write mode ?  What I 
am getting at is, should bfd_fopen() take an explicit extra parameter 
which tells BFD whether this file is intended for reading, writing or both ?

Cheers
  Nick