Front page | perl.perl5.porters |
Postings from April 2016
Re: Inconsistencies in memory size types
Thread Previous
|
Thread Next
From:
ilmari
Date:
April 6, 2016 10:08
Subject:
Re: Inconsistencies in memory size types
Message ID:
d8jbn5n123i.fsf@dalvik.ping.uio.no
Andy Dougherty <doughera@lafayette.edu> writes:
> 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.
size_t might not have been universally available when Size_t was
introduced, but now it definitely is (there are lots places in the core
that use it unconditionally). ssize_t however does not seem to be
available on Windows: SSize_t is #define'd to __int64 or int, depending
on word length.
> 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.)
The Configure probe for 'sizetype' only tests for size_t and unsigned
int, and all the canned configs set it to size_t.
>> 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?
STRLEN and MEM_SIZE are both equivalent to Size_t:
$ ag '^(#\s*define|typedef\s+\w+)\s+(MEM_SIZE|STRLEN)\b' *.h
perl.h
905:#define MEM_SIZE Size_t
2598:typedef MEM_SIZE STRLEN;
> 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.
This is why my patch makes Size_t, MEM_SIZE and STRLEN available #ifndef
PERL_CORE. On second though, though, standardising on Size_t and
SSize_t will make things easier for upstream-blead dual-life modules
(unless they all use Devel::PPPort and we add the defines there).
--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of." -- Skud's Meta-Law
Thread Previous
|
Thread Next