(int)(void*)(int) 64 vs 32
diff mbox

Message ID 20160224190642.GB3029@dub6
State Changes Requested
Headers show

Commit Message

Neels Hofmeyr Feb. 24, 2016, 7:07 p.m. UTC
On my 64bit system, I get warnings about casting int to pointer of
different size and vice versa. However, below patch only shifts the
warnings to 32bit systems, right?

Should we encapsulate in some #ifdef __i386__ or is there an always-native
int type?

Thanks
~Neels


From f25f8cebb58ad1f5241a33d9bac76654cd2a68a2 Mon Sep 17 00:00:00 2001
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Date: Wed, 24 Feb 2016 19:31:33 +0100
Subject: [PATCH] remove warning on 64bit, add warning on i386?

---
 openbsc/src/osmo-bsc/osmo_bsc_vty.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Harald Welte Feb. 24, 2016, 10:38 p.m. UTC | #1
On Wed, Feb 24, 2016 at 08:07:21PM +0100, Neels Hofmeyr wrote:
> On my 64bit system, I get warnings about casting int to pointer of
> different size and vice versa. However, below patch only shifts the
> warnings to 32bit systems, right?

I don't think so.  'long' typically corresponds to the pointer size, at
least based on my experience.  Of course the C standard doesn't give you
any guarantees and just states that it should be at least the size of a
signed 32bit integer.

according to page 6 of
http://www.agner.org/optimize/calling_conventions.pdf the only practical
exception seems to be windows, where on 64bit even a 'long' is only
32bit ;)

The more interesting question is probably why is vty->index not pointing
to 'struct osmo_msc_data' in the first place?  That's what we typically
use, rather than storing integers in the pointer and then perfomring
lookups on that.  Holger?
Jacob Feb. 25, 2016, 9:03 a.m. UTC | #2
Hi

On 24.02.2016 20:07, Neels Hofmeyr wrote:
> On my 64bit system, I get warnings about casting int to pointer of
> different size and vice versa. However, below patch only shifts the
> warnings to 32bit systems, right?
>
> Should we encapsulate in some #ifdef __i386__ or is there an always-native
> int type?

What about using uintptr_t from stdint.h ?

Jacob
Neels Hofmeyr Feb. 25, 2016, 11:25 a.m. UTC | #3
On Wed, Feb 24, 2016 at 11:38:36PM +0100, Harald Welte wrote:
> On Wed, Feb 24, 2016 at 08:07:21PM +0100, Neels Hofmeyr wrote:
> > On my 64bit system, I get warnings about casting int to pointer of
> > different size and vice versa. However, below patch only shifts the
> > warnings to 32bit systems, right?

> I don't think so.  'long' typically corresponds to the pointer size, at
> least based on my experience.  Of course the C standard doesn't give you
> any guarantees and just states that it should be at least the size of a
> signed 32bit integer.

> according to page 6 of
> http://www.agner.org/optimize/calling_conventions.pdf the only practical
> exception seems to be windows, where on 64bit even a 'long' is only
> 32bit ;)

can't do that then, can we ;)


On Thu, Feb 25, 2016 at 10:03:21AM +0100, Jacob wrote:
> What about using uintptr_t from stdint.h ?

    stdint.h:typedef unsigned long int  uintptr_t;

So that would work indeed. I'd have interpreted the name to mean
  unsigned int*
but it seems to be made for this specific case.

But I agree that the case per se is still odd:


On Wed, Feb 24, 2016 at 11:38:36PM +0100, Harald Welte wrote:
> The more interesting question is probably why is vty->index not pointing
> to 'struct osmo_msc_data' in the first place?  That's what we typically
> use, rather than storing integers in the pointer and then perfomring
> lookups on that.  Holger?

/me escalating to hfreyther

~Neels
Holger Freyther Feb. 25, 2016, 1:01 p.m. UTC | #4
> On 24 Feb 2016, at 23:38, Harald Welte <laforge@gnumonks.org> wrote:
> 
> 
> The more interesting question is probably why is vty->index not pointing
> to 'struct osmo_msc_data' in the first place?  That's what we typically
> use, rather than storing integers in the pointer and then perfomring
> lookups on that.  Holger?

I don't remember why I wanted to work with numbers. We can use the pointer to the struct.

holger

Patch
diff mbox

diff --git a/openbsc/src/osmo-bsc/osmo_bsc_vty.c b/openbsc/src/osmo-bsc/osmo_bsc_vty.c
index d871f01..1e4e6ee 100644
--- a/openbsc/src/osmo-bsc/osmo_bsc_vty.c
+++ b/openbsc/src/osmo-bsc/osmo_bsc_vty.c
@@ -43,7 +43,7 @@  static struct osmo_bsc_data *osmo_bsc_data(struct vty *vty)
 
 static struct osmo_msc_data *osmo_msc_data(struct vty *vty)
 {
-	return osmo_msc_data_find(bsc_gsmnet, (int) vty->index);
+	return osmo_msc_data_find(bsc_gsmnet, (int)(long int) vty->index);
 }
 
 static struct cmd_node bsc_node = {
@@ -70,7 +70,7 @@  DEFUN(cfg_net_msc, cfg_net_msc_cmd,
 		return CMD_WARNING;
 	}
 
-	vty->index = (void *) index;
+	vty->index = (void *)(long int) index;
 	vty->node = MSC_NODE;
 	return CMD_SUCCESS;
 }