mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org,
	Roman Zippel <zippel@linux-m68k.org>
Subject: Re: [patch 1/2] m68k: runtime patching infrastructure
Date: Wed, 30 May 2007 11:03:57 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0705301051580.26602@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0705300903030.31930@anakin>



On Wed, 30 May 2007, Geert Uytterhoeven wrote:
> 
> Apparently you get a warning only if the _first_ occurrence of a struct
> is declared inside a parameter list of a function.

This is normal C behaviour (and afaik, the "inside a parameter list" part 
is actually just _modern_ C, not traditional C. I _think_ traditional C 
had a single global namespace for struct names, and no scoping at all).

You can use a _pointer_ to a structure without declaring the structure 
itself, and this is totally standard C behaviour. The very use of the 
pointer will tell the C compiler that such a structure exists, and since 
you only use the pointer, the compiler doesn't care what the struct 
_looks_ like. It just adds it to its list of known structures.

In fact, you can often use such a pointer without _ever_ declaring the 
structure at all. The structure may not even _exist_. It may be just a way 
to get type safety, and every time you want to actually use the pointer, 
you have to explicitly cast it to something else.

(Example: in <stdio.h> you can do

	typedef struct dummy_made_up_struct FILE;

and make sure that everybody ever uses a "FILE *f", and trying to create a 
"FILE f" would be a compile-time error, because that "struct 
dummy_made_up_struct" simply doesn't even exist, and all the real users 
will cast it to some internal thing)

The reason the "inside a parameter list" is special is that modern C (I 
think through some obscure C++ reason, but I'm not sure) considers the 
function parameter list to be inside function scope, and that includes the 
types, not just the parameter names.

So when you do

	extern function(struct hello *);

without (forward-)declaring "struch hello" earlier, then the compiler will 
still create a "struct hello" internally, but since the scope of that 
declaration is purely just that function prototype itself, it will be 
forgotten immediately afterwards, and a subsequent use of "struct hello" 
will be considered a _different_ "struct hello", since it's in different 
scope.

So you generally never need to forward-declare structures, unless you only 
then use them inside function prototypes. In which case you would just do

	struct hello;

to tell the compiler that you have a "struct hello" that you haven't 
actually declared yet, and now it's in scope _outside_ the function 
prototype, and everybody is happy and agrees that they are using the same 
"struct hello".

		Linus

  parent reply	other threads:[~2007-05-30 18:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-28 19:16 [patch 0/2] A few more m68k patches Geert Uytterhoeven
2007-05-28 19:16 ` [patch 1/2] m68k: runtime patching infrastructure Geert Uytterhoeven
2007-05-30  0:38   ` Andrew Morton
2007-05-30  5:48     ` Eric Dumazet
2007-05-30  7:06       ` Geert Uytterhoeven
2007-05-30  8:20         ` Joerg Dorchain
2007-05-30 11:19           ` Geert Uytterhoeven
2007-05-30 11:40             ` Joerg Dorchain
2007-05-30  8:23         ` Andreas Schwab
2007-05-30 18:03         ` Linus Torvalds [this message]
2007-06-03 15:56     ` Wouter Verhelst
2007-05-28 19:16 ` [patch 2/2] m68k: Discontinuous memory support Geert Uytterhoeven
2007-05-30  0:44   ` Andrew Morton
2007-05-30  0:45   ` Andrew Morton

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=alpine.LFD.0.98.0705301051580.26602@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=zippel@linux-m68k.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

all inboxes | Powered by JetHome®