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

Re: Inconsistencies in memory size types

Thread Previous | Thread Next
June 21, 2016 14:16
Re: Inconsistencies in memory size types
Message ID:
Dave Mitchell <> writes:

> On Wed, Apr 06, 2016 at 09:26:24PM +0200, H.Merijn Brand wrote:
>> On Wed, 06 Apr 2016 11:08:33 +0100, (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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About