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

Re: Inconsistencies in memory size types

Thread Previous
From:
Andy Dougherty
Date:
June 23, 2016 21:02
Subject:
Re: Inconsistencies in memory size types
Message ID:
20160623210209.GA22237@fractal.phys.lafayette.edu
On Thu, Jun 23, 2016 at 11:42:08AM +0200, Aristotle Pagaltzis wrote:
> * Josh Juran <jjuran@gmail.com> [2016-06-21 21:24]:
> > On Jun 21, 2016, at 10:16 AM, ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) wrote:
> > > Any more votes the merits of (S)Size_t vs. (s)size_t?
> >
> > All other things being equal, I'd encourage using standard types over
> > equivalent non-standard types.
> 
> Same here.
> 
> To me it seems the most sensible approach to portability is the OpenBSD
> way: write the code to a reasonable baseline, then polyfill the missing
> bits of each platform with the portability layer.
> 
> Meaning, in perl’s case, Configure must probe for a sane ssize_t, and on
> platforms where it doesn’t find one, config.h must provide a reasonable
> fallback definition (i.e. whatever SSize_t would be on those platforms
> now, presumably). Then perl can use size_t/ssize_t like any conventional
> C project.

The reason we don't do it that way is that you would end up with lines
like this:

    #define ssize_t  long

which had two problems.  First, it's defining something that's supposed
to be in a reserved namespace.  (You can usually get away with it,
however.)  Second, if an XS extension includes another library header
that also tries to define ssize_t, you can end up with a conflict.
(You can protect against a #define with #ifndef ssize_t, but you can't
protect against a typedef.)  I seem to recall that sort of conflict did
pop up in the early days.

In short, Ssize_t is likely to be very safe.  These days, I suspect
#defining ssize_t would also likely work most of the time, so it's
probably not a big deal either way.  Still, my mild preference would be
to use size_t (because it's standard C) and Ssize_t (because it's POSIX,
not standard C).

-- 
    Andy Dougherty		doughera@lafayette.edu

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About