develooper Front page | perl.perl5.porters | Postings from September 2014

[perl #122861] [PATCH] for storage of NVs, use "IV in sv_u in head no-body trick" where possible

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
September 28, 2014 23:25
Subject:
[perl #122861] [PATCH] for storage of NVs, use "IV in sv_u in head no-body trick" where possible
Message ID:
rt-4.0.18-9614-1411946692-1456.122861-15-0@perl.org
On Sun Sep 28 14:07:50 2014, bulk88 wrote:
> On Sun Sep 28 10:37:37 2014, sprout wrote:
> > On Sun Sep 28 09:43:23 2014, bulk88 wrote:
> > > New patch attached. Due to issues raised on #p5p over NVU token
> > > being
> > > very short and therefore likely to conflict with 3rd party headers,
> > > I
> > > renamed it to a suggestions by dmq.
> >
> > Thank you.  Applied as 5b306eef3.
> >
> > However, clang is not happy about the change from size_t to U32 for
> > arena_size:
> >
> > sv.c:959:32: warning: implicit conversion from 'unsigned long' to
> > 'U32'
> >       (aka 'unsigned int') changes value from 18446744073709551600 to
> > 4294967280
> 
> http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html
> 
> 18446744073709551600 = 0xFFFF FFFF FFFF FFF0
> 4294967280 = 0xFFFF FFF0
> 
> C:\Documents and Settings\Owner>perl -E "say unpack('l',
> pack('L',0xFFFFFFF0))"
> -16
> 
> Maybe the right value for that field is I32 and not the U32 and size_t
> (IIRC is unsigned) before the U32 in my patch.
> 
> > [-Wconstant-conversion]
> > FIT_ARENA(0, sizeof(XPV) - STRUCT_OFFSET(XPV, xpv_cur)) },
> >           ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > sv.c:923:26: note: expanded from macro 'FIT_ARENA'
> > ? FIT_ARENAn (count, body_size)                     \
> >                    ^
> > sv.c:919:15: note: expanded from macro 'FIT_ARENAn'
> > ? count * body_size                                 \
> >         ^
> >
> > While I can go ahead and add the cast (I plan to), this
> > 18446744073709551600 confuses me.  Where is that number coming from?
> > How did sizeof(XPV) - STRUCT_OFFSET(XPV, xpv_cur) end up negative (if
> > that is what is happening)?
> 
> sizeof(XPV) is 0x10 on my 32 bit system
> STRUCT_OFFSET(XPV, xpv_cur) is 0x8 on my 32 bit system
> FIT_ARENA(0, sizeof(XPV) - STRUCT_OFFSET(XPV, xpv_cur)) is 0x0F68 on
> my 32 bit system
> 
> 0x10-0x8 is 0x8 so IDK why its negative
> 
> Finally one of the macros in FIT_ARENA is
> 
> #define FIT_ARENA0(body_size)                           \
>     ((size_t)(PERL_ARENA_SIZE / body_size) * body_size)
> 
> notice the "size_t" cast.
> 
> I dont have an answer why it is negative

I think it’s a bug in clang’s warnings.  I could only suppress it by casting the entire macro result (cd1dc8e2c73b), which I know is actually 3536.

As far as I can tell, this ticket can be closed now, can’t it?

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=122861

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About