develooper Front page | perl.perl5.porters | Postings from July 2012

removing pre-ANSI support (was Re: SSize_t, Size_t, size_t)

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
July 13, 2012 03:35
Subject:
removing pre-ANSI support (was Re: SSize_t, Size_t, size_t)
Message ID:
20120713103521.GI9583@plum.flirble.org
On Tue, Jun 12, 2012 at 04:13:05PM -0700, Rev. Chip wrote:
> I think STRLEN, MEM_SIZE, and Size_t should be straight-up no-configure
> typedefs or defines of size_t now, kept only for backcompat of XS code; and
> the Perl source code proper should use size_t throughout.  C89 is oooold
> now; we can count on it.

Should we also have a (documented) policy of progressively removing other
things that were needed to work around pre-C89 compilers, and other dead
things?

Specifically, I'm aware of

VOL         in case your pre-C89 compiler doesn't understand volatile
StructCopy  in case your pre-C89 compiler can't copy structures
STATIC      under PerlObject, static functions were actually private methods

What else is there?

I don't know if it's worth having a one time purge on these, or stating that
new and edited code should use the better forms.

Specifically, from the point of view of blame logs for history spelunking,
STATIC only happens on the start of a line, and only shares it with the
function's return type or prototype, which rarely changes. This also makes it
unlikely to cause lots of pain with patch cherry picking.

VOL is rare. It's simply not going to be a big deal on either.

I assumed that StructCopy was endemic, but it's not. It's also not in
platform specific code. So it's probably not a big deal.


The historic "big deal" that was really frustrating when it came to cherry
picks (conflicts!) and still is when it comes to blame analysis of what
changed when, are commits that make minor changes to the variables or
structures of a lot of functions, orthogonal to functionality and orthogonal
to source file*. These have small substantive gain (but if not done carefully
can and did introduce bugs https://rt.perl.org/rt3/Ticket/Display.html?id=77300
), but turned out to have long term subtle costs.

Nicholas Clark

* source file mattered under perforce, because of the granularity of how it
  tracks what has been integrated. But until I worked with it a lot, I didn't
  appreciate that a lot of the code paths/functional groupings in perl 5
  cross-cut the source files, instead of going with them. The source files
  are not the only dimension that matters.

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