public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sylvester Diehl <diehl@dachau.marco.de>
To: dave.korn@artimi.com (Dave Korn)
Cc: Joe.Buck@synopsys.COM, gcc@gcc.gnu.org
Subject: Re: attribute initialized
Date: Wed, 13 Jul 2005 14:09:00 -0000	[thread overview]
Message-ID: <m1DshuV-007uSOC@hera.dachau.marco.de> (raw)
In-Reply-To: <SERRANOB1t93Lx9w5dR000004aa@SERRANO.CAM.ARTIMI.COM> from Dave Korn at "Jul 12, 05 10:33:56 am"

> ----Original Message----
> >From: Joe Buck
> >Sent: 11 July 2005 20:07
> 
> > On Mon, Jul 11, 2005 at 08:07:20PM +0200, Sylvester Diehl wrote:
> >> why doesn't gcc (-Wall -Wuninitalized -O) detect
> >> an uninialized variable passed by reference
> >> decleared as <type> const *<name> ?
> > 
> > There are no uninitialized variables in your program.  For the
> > kind of access checking you seem to be asking for, you'll need
> > something like valgrind or mudflap.
> > 
> >> int foo(int const *p)
> >> {
> >> 	static int sum = 0;
> >> 
> >> 	sum += *p;
> >> 	return sum;
> >> }
> > 
> > it happens that the memory that p points to is unitialized, but
> > that is not what -Wuninitialized does.  Similarly, in
> > 
> >> int main(int argc, char **argv)
> >> {
> >> 	int k;
> >> 
> >> 	return printf("%d\n", foo(&k));
> >> }
> > 
> > there are no uninitialized variables, as the address of k is
> > perfectly well defined.
> 
>   Indeed so, but I think Sylvester's point is that given that foo takes a
> const pointer, the compiler could theoretically know that foo cannot
> legitimately make any use of (dereference) the pointer value being passed
> and could perhaps issue a warning.

My inital point was a function which gets parameters as pointers
and this pointers have to point to something initalized.
Passing the values gives me the expected warning.
However it's more efficent to refer big data structures
to a function with a pointer.

Now i was looking for a posibility to clearify this the compiler.

I didn't find an adequate attribute.
The use of const was a trial to issue a warning.
I favored an attribute.

cheers,
Sylvester

> 
>   Myself, I was surprised that the inliner didn't catch on to what was going
> on and complain.  I would have expected that, but it didn't even at O3.
> 
>     cheers,
>       DaveK

      parent reply	other threads:[~2005-07-13 14:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-11 18:07 Sylvester Diehl
2005-07-11 19:06 ` Joe Buck
2005-07-12  9:34   ` Dave Korn
2005-07-12  9:56     ` Falk Hueffner
2005-07-12  9:56       ` Dave Korn
2005-07-13 14:09     ` Sylvester Diehl [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=m1DshuV-007uSOC@hera.dachau.marco.de \
    --to=diehl@dachau.marco.de \
    --cc=Joe.Buck@synopsys.COM \
    --cc=dave.korn@artimi.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).