develooper Front page | perl.perl5.porters | Postings from April 2016

Re: Inconsistencies in memory size types

Thread Previous | Thread Next
Andy Dougherty
April 6, 2016 01:28
Re: Inconsistencies in memory size types
Message ID:
On Tue, Apr 05, 2016 at 03:28:04PM +0100, Dave Mitchell wrote:
> On Tue, Mar 01, 2016 at 09:46:17AM +0000, Dagfinn Ilmari Mannsåker wrote:
> > Hi porters,
> > 
> > While investigating [perl #127619] Broken memcpy() fallback to bcopy(),
> > I noticed that variables refering to string lengths, array sizes
> > etc. are an inconsistent mess of MEM_SIZE, STRLEN, Size_t and size_t
> > (and SSize_t/ssize_t for signed variants).  A bit more digging reveals
> > that we already use size_t unconditionally all over the codebase (and
> > it's required by C89), while ssize_t support is more patchy (it's only
> > required by POSIX, not ISO/ANSI C).
> > 

> SSize_t and Size_t seem to have been added in perl 5.000 in 1994, but
> there's no indication of the rationale. The 5.000 src code was still
> K&R in at least function signatures, so it may well be the case that
> that size_t wasn't universal at that time or was problematic on some
> platforms.

Sorry about that :-).

Size_t and SSize_t were intended as portable stand-ins for size_t and
ssize_t, with the idea that they could be used everywhere.  At the time,
you couldn't rely on ssize_t, and I'm pretty sure you also couldn't
rely on size_t.  STRLEN was subtly different -- it was supposed to be
the type of argument used in various string functions.  I don't have my
old manuals handy at the moment, but I seem to recall that the string
functions weren't all consistent about whether they wanted signed or
unsigned, int or long.  (That's why the old Perl_my_bcopy( ) prototype
conflicted with the more modern bcopy( ) function.)

> I feel slightly twitchy about eliminating Size_t etc, but can't think
> of any rational reason why.
> Do any C lawyers and/or people who used to port perl to crays, know
> whether there are any semantic differences between size_t, MEM_SIZE,
> STRLEN etc?

I don't think there are issues anymore.  Unfortunately, XS code likely
uses a mix of Size_t, MEM_SIZE, and STRLEN, so I'm not sure there's
much you can actually do.

    Andy Dougherty

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