mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Thunder from the hill <thunder@ngforever.de>
Cc: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
	M?ns Rullg?rd <mru@users.sourceforge.net>,
	Mohamed Ghouse Gurgaon <MohamedG@ggn.hcltech.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: Diff b/w 32bit & 64-bit
Date: Sun, 7 Jul 2002 22:24:25 +0100	[thread overview]
Message-ID: <20020707222425.A12535@kushida.apsleyroad.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0207071338570.10105-100000@hawkeye.luckynet.adm>; from thunder@ngforever.de on Sun, Jul 07, 2002 at 01:41:35PM -0600

Thunder from the hill wrote:
> > > don't cast from "foo *" to "bar *" if sizeof(foo)<sizeof(bar)
> > 
> > What is the reason for this?  I do it quite routinely ("poor man's
> > inheritance").
> 
> This should only be OK if you pad bar before.

Erm, crossed wire :-)

I do it for inheritance in the same way as, say, Xlib with X events.
That's perfectly safe and commonplace.

I didn't understand Albert's reason for prohibiting the mere cast.
(Notions of old machines where the char * representation is different
from int * came to mind, but Linux doesn't run on those... does it?)

Oliver Neukum explained that you shouldn't dereference a pointer to a
larger type because of alignment issues on some machines.
sizeof(foo)<sizeof(bar) captures this rule just fine for the basic data
types (char, int etc.).

But for structures, it's actually possible to have a smaller type with a
larger alignment requirement, and vice versa:

     struct small { double x; };
     struct large { char y [11]; };

Also, it is certainly permitted to cast "char *" to "int *" if you know
that the underlying object is an "int" or something compatible with one.

So, the general rule `don't cast from "foo *" to "bar *" if
sizeof(foo)<sizeof(bar)' is wrong, and is routinely not followed.

An alternative rule might be `never dereference a "bar *" if it might
not have the correct alignment for "bar" on any platform'.

-- Jamie

  reply	other threads:[~2002-07-07 21:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-01 10:23 Mohamed Ghouse , Gurgaon
2002-07-01 19:44 ` Måns Rullgård
2002-07-01 21:45   ` Johannes Ruscheinski
2002-07-02 19:02     ` Måns Rullgård
2002-07-01 21:52   ` Albert D. Cahalan
2002-07-02 19:03     ` Måns Rullgård
2002-07-02 19:18       ` Richard B. Johnson
2002-07-07 18:12     ` Jamie Lokier
2002-07-07 19:41       ` Thunder from the hill
2002-07-07 21:24         ` Jamie Lokier [this message]
2002-07-08 20:34           ` Albert D. Cahalan

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=20020707222425.A12535@kushida.apsleyroad.org \
    --to=lk@tantalophile.demon.co.uk \
    --cc=MohamedG@ggn.hcltech.com \
    --cc=acahalan@cs.uml.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mru@users.sourceforge.net \
    --cc=thunder@ngforever.de \
    /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®