From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13445 invoked by alias); 7 Jun 2005 15:53:28 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13409 invoked by uid 22791); 7 Jun 2005 15:53:23 -0000 Received: from admin.voldemort.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 07 Jun 2005 15:53:23 +0000 Received: (qmail 14905 invoked from network); 7 Jun 2005 15:53:21 -0000 Received: from localhost (HELO ?192.168.0.5?) (mitchell@127.0.0.1) by mail.codesourcery.com with SMTP; 7 Jun 2005 15:53:21 -0000 Message-ID: <42A5C2EA.3070906@codesourcery.com> Date: Tue, 07 Jun 2005 15:53:00 -0000 From: Mark Mitchell User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Nick Clifton CC: binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: PATCH: Avoid accidentally opening files for write References: <200506070717.j577HNq4006430@sethra.codesourcery.com> <42A566C9.4040500@redhat.com> In-Reply-To: <42A566C9.4040500@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg00056.txt.bz2 Nick Clifton wrote: > 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 ? I did not test in a non-POSIX *build* environment, but I did test in a non-POIX *target* environment. In particular, I built a MinGW GDB using a GNU/Linux host, and verified that this fixed the bug. (I used an older version of GDB that still had a tendency to mangle its output; using this patch stopped it from doing the mangling because it no longer tried to write out the file.) > 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. I didn't know about that, but will try it before check-in. Just a build, or should I try to run some kind of testsuite as well? (Is there a way to run the binutils testuite on all targets all at once?) >> ! 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 ? Hmm. In practice, we always use one of the FOPEN_* macros as an argument, and these do follow the rules implied by what I wrote. But, I could tighten the test to check for just what ISO C requires, which is that the characters must occur at the start of the string, so using strchr is probably incorrect. OK to make that change before check-in, or would you like me to resubmit? I'm not aware of OSes that do as you say, but, in any case, I don't think we need to worry about OSes that accept other variations. Clients of BFD should be using the standard syntax. It's OK if they use OS extensions, but I think it's reasonable to say that if they mean "read" they use "r" and not "R". -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com (916) 791-8304