Re: PATCH: Avoid accidentally opening files for write

Nick Clifton
2005-06-07T09:18:05Z

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