All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] integer -> pointer question
Date: Mon, 31 Jul 2000 23:21:21 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590678205256@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590678205250@msgid-missing>

>>>>> On Mon, 31 Jul 2000 15:22:09 -0700 (PDT), Michael Madore <mmadore@turbolinux.com> said:

  Michael> Hi, When porting packages to IA64, it is very common to
  Michael> come across code where integers are being assigned to
  Michael> pointers.  This results in warning messages from the
  Michael> compiler about assigning integers to pointers of a
  Michael> different size.

  Michael> This is very helpful in the case where a function prototype
  Michael> has been omitted, or the programmer has simply made bad
  Michael> assumptions about the sizes of pointers and integers.

  Michael> On the other hand, it is not unusual to see void pointers
  Michael> used for storing integers, and the programmer has no
  Michael> intention of ever de-referencing the pointer.  Glib and
  Michael> GTK+ make extensive use of this technique.

It's sad that GTK/Glib is propagating this poor programming habit.
The clean solution is to use a union type such as:

	typedef union {
		void *v;
		long l;
		int i;
		char c;
		float f;
		double d;
		...other types you might like...;
	} any_type_t;

and then you can assign to a variable of type "any_type_t" without any
ugly casts.  It also makes it much clearer what the intended use of
the argument in question is.  If you don't like the additional
any_type_t variables you need to declare in return, you can avoid even
that by introducing cpp macros of the form:

	#define int_to_any_type(i)	({any_type_t a; a.i = i;})
	#define long_to_any_type(i)	({any_type_t a; a.l = l;})
	etc.

Unfortunately, it's unlikely that GTK/Glib will be fixed soon in this
respect, so in the meantime, just use the cast "(void *)(long) i" if
"i" is an integer.

	--david



  parent reply	other threads:[~2000-07-31 23:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-31 22:22 [Linux-ia64] integer -> pointer question Michael Madore
2000-07-31 22:34 ` Jes Sorensen
2000-07-31 23:03 ` Dan Pop
2000-07-31 23:14 ` Michael Madore
2000-07-31 23:16 ` Michael Madore
2000-07-31 23:20 ` Dan Pop
2000-07-31 23:21 ` David Mosberger [this message]
2000-08-01  0:49 ` Jes Sorensen

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=marc-linux-ia64-105590678205256@msgid-missing \
    --to=davidm@hpl.hp.com \
    --cc=linux-ia64@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.