| Message ID | 20160224190642.GB3029@dub6 |
|---|---|
| State | Changes Requested |
| Headers | show |
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?
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
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
> 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
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; }
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(-)