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

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

Thread Previous | Thread Next
Father Chrysostomos via RT
July 23, 2013 05:15
[perl #116907] perl doesn't handle m{}g for >= 2GB files even with largefiles and 64bitall
Message ID:
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)?

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


XpoR	|SSize_t*|hv_placeholders_p	|NN HV *hv



Father Chrysostomos

via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About