public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joerg Dorchain <joerg@dorchain.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@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 10:20:35 +0200	[thread overview]
Message-ID: <20070530082035.GA8200@Redstar.dorchain.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0705300903030.31930@anakin>

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Wed, May 30, 2007 at 09:06:08AM +0200, Geert Uytterhoeven wrote:
[...]
> > > 
> > > I think it could be tightened up even if it happens not to warn?
> > 
> > 
> > struct a {
> > 	struct not_yet_defined *start, *end;
> > };
> > 
> > struct not_yet_defined {
> > 	void *foo;
> > };
> > 
> > Is a valid and gives no warnings.
> 
> I was puzzled by this as well, as there were no compiler warnings...

Pointers are (at least on m68k) of known size, so the compiler knows how
much space the struct occupies.

Type checking is by definition futile with void * pointer, but for all
other cases the compiler has all types and sizes it needs at this point.

The actual dereferencing of the symbol table is done by the linker,
which also knows all locations and sizes it needs.

Actually, this is the only way to define circular referencing
structures.

A one-pass-compiler-linker would run into problems.

Joerg, trying to recall compiler construction lessons

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-05-30  8:40 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 [this message]
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
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=20070530082035.GA8200@Redstar.dorchain.net \
    --to=joerg@dorchain.net \
    --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=torvalds@linux-foundation.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