public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eyal Lebedinsky <eyal@eyal.emu.id.au>
To: "list, gcc" <gcc@gcc.gnu.org>, "Eigler, Frank Ch." <fche@redhat.com>
Subject: fread()
Date: Tue, 08 Apr 2003 11:18:00 -0000	[thread overview]
Message-ID: <3E929948.7413C5B2@eyal.emu.id.au> (raw)

I finally tracked down the errors in my sort algorithm. Turns out
that fread() does not mark the buffered as written to.

I could easily create a patch for a wrapper [my current solution
is to add "buffer[0] = 0;" before my fread()] but I want to
first know how mudflap is supposed to handle this. Does it use
any rules to decide which pointers passed to external functions
should be treated as being written to? A wrapper can go further
and verify that the whole buffer area (based on size*count) is
valid - but this is a separate point.

Maybe I should ask if there is any more doco I can read (for now
I am reading the sources). I think I now understand the basics of
mf since it looks very much like the debugging system I already
have in my software. I since learnt that mf keeps track of read/
write accesses - does it track anything else?


Anyway, after clearing a few more hurdles I am now seeing real
error reports. This is very good and I hope to use it on a regular
basis. I just need it to be multithread safe to be able to run my
full system through it.

I now use a perl script to decode the reports into proper
file:line which makes them drastically more usefull. I hope the
author will be ready to post it tomorrrow. This is a first
attempt, using gdb to get symbol info, and we may (time
permitting) look at a proper patch to generate a nicer traceback
in the first place.

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>

                 reply	other threads:[~2003-04-08  9:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=3E929948.7413C5B2@eyal.emu.id.au \
    --to=eyal@eyal.emu.id.au \
    --cc=fche@redhat.com \
    --cc=gcc@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).