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

Re: Inconsistencies in memory size types

Thread Previous | Thread Next
From:
ilmari
Date:
June 21, 2016 14:16
Subject:
Re: Inconsistencies in memory size types
Message ID:
d8jy45yiq4i.fsf@dalvik.ping.uio.no
Dave Mitchell <davem@iabyn.com> writes:

> On Wed, Apr 06, 2016 at 09:26:24PM +0200, H.Merijn Brand wrote:
>> On Wed, 06 Apr 2016 11:08:33 +0100, ilmari@ilmari.org (Dagfinn Ilmari
>> Mannsåker) wrote:
>> 
>>> 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).
>> 
>> Which is what I wanted to suggest. Make the core cleaner and have all
>> backward compat available in Devel::PPPort should only cause a *little*
>> extra effort on those XS modules that do not use it correct. It is
>> unlikely to affect end users and cpan clients
>
> My current preference is that core standardises on Size_t and SSize_t,
> and eliminates usage of size_t, ssize_t, STRLEN and MEM_SIZE.

I've pushed a branch smoke-me/ilmari/Size_t which converts all non-cpan/
uses of STRLEN and MEM_SIZE to Size_t, and uses of ssize_t to SSize_t.

I haven't touched the uses of size_t yet, since I'm unsure about whether
to convert ones that are used for libc APIs that are defined to use
size_t.  It's safe to do, since $Config{sizetype} is size_t everywhere,
but it feels a bit pointless.

Any more votes the merits of (S)Size_t vs. (s)size_t?

-- 
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least.               - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article.                      - Calle Dybedahl


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