From: Paul Schlie <schlie@comcast.net>
To: <gdb-patches@sources.redhat.com>
Cc: "Theodore A. Roth" <troth@openavr.org>, Andrew Cagney <cagney@gnu.org>
Subject: Re: [RFA] initialize err variable in load_section_callback()
Date: Fri, 14 Jan 2005 23:29:00 -0000 [thread overview]
Message-ID: <BE0DC01A.8A45%schlie@comcast.net> (raw)
In-Reply-To: <BDFFB08B.877A%schlie@comcast.net>
If preferred, here's an alternate fix:
In File target.c,
int
target_write_memory_partial (CORE_ADDR memaddr, char *buf, int len, int
*err)
{
if (target_xfer_partial_p ())
+ {
+ *err = 0;
return target_xfer_partial (target_stack, TARGET_OBJECT_MEMORY, NULL,
NULL, buf, memaddr, len);
+ }
else
return target_xfer_memory_partial (memaddr, buf, len, 1, err);
}
target_xfer_partial nor it's predecessor sets *err, therefore uninitialized.
(bug introduced in version 1.83, by checkin on 9/30/04 by Andrew Cagney)
> From: Paul Schlie <schlie@comcast.net>
> Date: Tue, 04 Jan 2005 02:31:39 -0500
> To: <gdb-patches@sources.redhat.com>
> Cc: "Theodore A. Roth" <troth@openavr.org>, Andrew Cagney <cagney@gnu.org>
> Subject: Re: [RFA] initialize err variable in load_section_callback()
>
> Might Ted please be given authorization to check his October patch into
> both the 6.3 and head branches, as it fixes an uninitialized variable problem
> which has already been subsequently independently found with identical fixes
> proposed at least a few times since:
>
> http://sources.redhat.com/ml/gdb-patches/2004-10/msg00324.html
>
> (Although there appeared to be some discussion with Andrew on the subject,
> this fix should be considered the least fragile way to guarantee that
> the err variable declared within this function's scope is initialized,
> as it's likely too fragile to assume that all functions which may signal
> errors, explicitly also signal success [other than via the absents of an
> error, which typically necessitates the utilized shared signaling variable
> be initialized as being error-free]. Where then if there is a desire to
> check/refined all error signaling functions within GDB such that they both
> explicitly signal success and failure, and guarantee that at least one
> such function is always called to initialize otherwise un-initialized error
> variables prior to being tested, this may be done independently of this
> proposed simple less fragile quick fix.)
>
next prev parent reply other threads:[~2005-01-14 23:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-04 7:31 Paul Schlie
2005-01-14 23:29 ` Paul Schlie [this message]
2005-01-27 19:38 ` PING: " Paul Schlie
-- strict thread matches above, loose matches on Subject: below --
2004-12-02 14:45 Paul Schlie
2004-10-19 20:22 Theodore A. Roth
2004-10-20 17:34 ` Andrew Cagney
2004-10-20 18:07 ` Theodore A. Roth
2004-10-26 0:04 ` Andrew Cagney
2004-10-26 18:19 ` Theodore A. Roth
2004-12-28 9:10 ` Theodore A. Roth
2005-03-04 17:51 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BE0DC01A.8A45%schlie@comcast.net \
--to=schlie@comcast.net \
--cc=cagney@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=troth@openavr.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox