From: Paul Schlie <schlie@comcast.net>
To: Andrew Cagney <cagney@gnu.org>
Cc: <gdb-patches@sources.redhat.com>, "Theodore A. Roth" <troth@openavr.org>
Subject: PING: [RFA] initialize err variable in load_section_callback()
Date: Thu, 27 Jan 2005 19:38:00 -0000 [thread overview]
Message-ID: <BE1EAD42.8CA1%schlie@comcast.net> (raw)
In-Reply-To: <BDFFB08B.877A%schlie@comcast.net>
Andrew, As it's been 3 months since this patch was posed which correctly
fixes a bug introduced a few weeks earlier by a check-in you made late
September '04, might you please consider checking this fix in please?
It would be very helpful if this can be done for both 6.3.x and HEAD
in support of targets which rely on this code path remaining functional.
[ For reference, although you had raised the question if this was the
correct fix; it actually is as evidenced by the following description
of target_xfer_memory (...), which clearly states that the function will
return a value of 0 upon a success, or an errno code will be set upon
upon failure (which isn't unusual, as typically only errors, not their
absents, are typically signaled through shared variables, therefore
relies upon the caller to initialize the errno code to 0 prior to
calling any function which may signal an error, which the function
(load_section_callback) in symfile.c does not properly presently do
prior to calling target_xfer_memory (...) which only guarantees to
signal failure per it's documented behavior since your check-in of
modifications to this function's implementation this past September.) ]
(in: target.c)
/* Transfer LEN bytes between target address MEMADDR and GDB address
MYADDR. Returns 0 for success, errno code for failure (which
includes partial transfers -- if you want a more useful response to
partial transfers, try either target_read_memory_partial or
target_write_memory_partial). */
static int target_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len,
int write);
> From: Paul Schlie <schlie@comcast.net>
>
> 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.)
>
prev parent reply other threads:[~2005-01-27 19:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-04 7:31 Paul Schlie
2005-01-14 23:29 ` Paul Schlie
2005-01-27 19:38 ` Paul Schlie [this message]
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=BE1EAD42.8CA1%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