From: Pavel Roskin <proski@gnu.org>
To: Thomas Schmid <Thomas.Schmid@br-automation.com>
Cc: linux-sparse@vger.kernel.org
Subject: Re: Antwort: Re: Antwort: Re: Messing typedefs?
Date: Fri, 29 Jun 2007 19:31:55 -0400 [thread overview]
Message-ID: <1183159915.13955.24.camel@dv> (raw)
In-Reply-To: <OFC8B6B106.51212EE6-ONC1257307.00233A24-C1257307.0025B204@br-automation.com>
On Wed, 2007-06-27 at 08:51 +0200, Thomas Schmid wrote:
> > My interpretation of the code is following. Types may have idents,
> > which keep information where and how the type was defined. Base types
> > don't have idents.
>
> But unfortunately they get one.
I understand it better now. Suppose we have:
typedef struct {int a;} foo;
int main(int argc, char **argv)
{
foo bar;
bar.x = 1;
}
The structure is indeed unnamed. If the error message is going to call
the _structure_ by name, it's correct to call it unnamed.
One possible fix would be to have an "inherited ident", which would be
set only by that code in external_declaration(). This would leave basic
types alone.
Then we need to come with a message that would be printed if only the
inherited ident is present. gcc prints:
test.c:5: error: 'foo' has no member named 'x'
No "struct" is mentioned. If we want to be more verbose, we could print
something like:
test.c:5:5: error: no member 'x' in struct type foo
Another solution would be to remove the ident setting code and try to
find the typedef name directly in evaluate_member_dereference().
--
Regards,
Pavel Roskin
prev parent reply other threads:[~2007-06-29 23:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 11:59 Messing typedefs? Thomas Schmid
2007-06-13 5:22 ` Pavel Roskin
2007-06-26 8:23 ` Antwort: " Thomas Schmid
2007-06-27 5:01 ` Pavel Roskin
2007-06-27 6:51 ` Antwort: " Thomas Schmid
2007-06-29 23:31 ` Pavel Roskin [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=1183159915.13955.24.camel@dv \
--to=proski@gnu.org \
--cc=Thomas.Schmid@br-automation.com \
--cc=linux-sparse@vger.kernel.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 NNTP newsgroup(s).