Front page | perl.perl5.porters |
Postings from February 2012
On Wed, Feb 29, 2012 at 08:22:47PM +1100, Tony Cook wrote: > On Wed, Feb 29, 2012 at 08:32:20AM +0100, H.Merijn Brand wrote: > > Ping. Nobody vented any opinion. Do we (have to) care? > > > > On Fri, 3 Feb 2012 11:46:15 +0100, "H.Merijn Brand" > > <h.m.brand@xs4all.nl> wrote: > > > > > HP-UX 11.31/64 U rx2660/64 Itanium 2 9100/1710(2) ia64 > > > "DBI.xs", line 1469: warning #4232-D: conversion from "XPVHV *" to a more > > > strictly aligned type "XPVMG *" may cause misaligned access > > > PerlIO_printf(DBILOGFP,"%s CachedKids %d\n", pad, (int)HvKEYS(> > > > > perl-5.14.2 > perl Porting/expand-macro.pl HvKEYS > > > `sh cflags "optimize='+O2 +Onolimit'" try.c` -E try.c > try.i > > > CCCMD = cc -DPERL_CORE -c -Ae -DPERL_DONT_CREATE_GVSV +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit > > > #line 4 "HvKEYS expands to" > > > ((((XPVHV*) (A0)->sv_any)->xhv_keys) - (((XPVMG*) (A0)->sv_any)->xmg_u . xmg_magic ? Perl_hv_placeholders_get( (const HV *)A0) : 0)) > > As long as sv_any actually contains a XPVMG * it should be safe > enough. Well in this case sv_any usually contains a XPVHV*. The issue is that the PVHV struct (which in this case just contains some 64-bit values) is a subset of the XPVMG, which also contains a 128-bit value (a long double). Thus XPVMG must be aligned on a 128-bit boundary, while an XPVHV only needs to be 64-bit aligned. Given however that the use of the XPVMG cast is only to access the 64-bit xmg_u field and not the later 128-bit xnv_u field, I think its safe. -- Never work with children, animals, or actors.Thread Previous