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 DybedahlThread Previous | Thread Next