develooper Front page | perl.perl5.porters | Postings from August 2013

Re: [perl #116907] perl doesn't handle m{}g for >= 2GB files evenwith largefiles and 64bitall

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
August 30, 2013 14:55
Subject:
Re: [perl #116907] perl doesn't handle m{}g for >= 2GB files evenwith largefiles and 64bitall
Message ID:
20130830145537.GX66035@plum.flirble.org
On Mon, Jul 22, 2013 at 10:15:05PM -0700, Father Chrysostomos via RT wrote:
> On Mon Jun 24 18:22:12 2013, sprout wrote:
> > On Sun Mar 03 06:48:09 2013, LeonT wrote:
> > > AFAICT changing mg_len shouldn't break API unless someone is taking a
> > > pointer to it, which doesn't seem very likely.
> > 
> > I have just searched CPAN for /&.*mg_len/.  The only uses of it are in
> > the perl core.
> 
> One of those uses is Perl_hv_placeholders_p.  Added in ca732855658630,
> this function is marked as being in the public API (A in embed.fnc), but
> has no documentation and no short form (hv_placeholders_p).  There are
> no uses of it on CPAN.
> 
> Is this another case where a function was mistakenly added to the API
> (like stashpv_hvname_match, added in ed221c5717 and removed in
> c947b31cf14), whereas it should simply have been exported (X in embed.fnc)?

Not intentionally. See below:

> The only use of this function *anywhere* in publicly-viewable code (OK,
> just CPAN and the perl core) is the HvPLACEHOLDERS macro in hv.h.
> 
> Only one CPAN module, Data::Alias, uses HvPLACEHOLDERS, and it is like
> this: HvPLACEHOLDERS(a2)++.
> 
> So it looks as though it is safe to change
> 
> ApoR	|I32*	|hv_placeholders_p	|NN HV *hv
> 
> to
> 
> XpoR	|SSize_t*|hv_placeholders_p	|NN HV *hv
> 
> Comments?

Yes, I think it's safe to do this (given the lack of users, and the compiler
warning that will ensue from anyone else using it and now having the wrong
size).


But this has been bugging me for quite a bit.
I know that we've got a lot of them, but I'm not sure that I like LVALUE
macros. In particular, I'm not sure that I like them to keep increasing,
and be the official documented route in. In that

1) LVALUE macros make it very hard to refactor the internals.
   Having a GET() and SET() pair makes the intent of the caller easy to spot.
   Which means that the storage doesn't need to stay as the same type as it
   is.

   You can also trigger code to run on writing the value, but avoid running
   it on reading. (For example, default the value to 0, and only do work if
   it's set to non-0)
   You can't do this with an LVALUE macro, because you can't tell reads from
   writes.

   I don't think that anyone is going to try to do any refactoring as
   aggressive as PONIE in the future, but by adding LVALUE macros we don't
   make their lives easier.

   *_p functions look ugly, which was sort of part of the plan.

2) Unlike functions, macros don't have any way to formally document their
   type. Which is directly relevant here. hv_placeholders_p has a clearly
   defined size of integer, which matters for pointers.
   Whereas the expression &HvPLACEHOLDERS(a2) doesn't, because you can't
   know what size HvPLACEHOLDERS(a2) is from its macro declaration. You have
   to dig further.


I don't have an answer here, and I'm not sure if I'm mentally prioritising
the wrong things to clean up first.


Ultimately I think that the problem is that the use of lots of direct data
structure access (even if the structure's shape is abstracted by macros) is
not malleable enough to survive major and continued refactoring. And that
we're way too far down that road to retrace our steps to a better place.

Nicholas Clark

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