From @Leont

Created by @Leont

A whole bunch of PerlIO symbols are currently exported through by
being hardcoded in makedef.pl, unlike most functions. This is because
the exact circumstances in which they are exported are more
complicated than makedef can currently handle.

This means however that we have about 80 'X' symbols (exported but not
officially part of the API), without anyone realizing. This is a bad
thing IMO. On the short term, I would suggest moving them to a more
visible place, though that requires either adding some logic to
makedef or dropping SFIO support.

On the longer term, we should either drop symbols or make them API,
probably on a case-by-case basis.

Flags:
    category=core
    severity=wishlist

Site configuration information for perl 5.14.2:

Configured by leon at Sun Nov 27 14:38:29 CET 2011.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:

  Platform:
    osname=linux, osvers=3.0.0-13-generic, archname=x86_64-linux
    uname='linux leon-laptop 3.0.0-13-generic #22-ubuntu smp wed nov 2
13:27:26 utc 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-de -Dprefix=/home/leon/perl5/perlbrew/perls/perl-5.14.2'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.6.1', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib
/usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib
-fstack-protector'

Locally applied patches:



@INC for perl 5.14.2:
    /home/leon/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/x86_64-linux
    /home/leon/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2
    /home/leon/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/x86_64-linux
    /home/leon/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2
    .


Environment for perl 5.14.2:
    HOME=/home/leon
    LANG=en_US.utf8
    LANGUAGE=en_US:en_GB:en
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/leon/perl5/perlbrew/bin:/home/leon/perl5/perlbrew/perls/perl-5.14.2/bin:/home/leon/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PERLBREW_HOME=/home/leon/.perlbrew
    PERLBREW_PATH=/home/leon/perl5/perlbrew/bin:/home/leon/perl5/perlbrew/perls/perl-5.14.2/bin
    PERLBREW_PERL=perl-5.14.2
    PERLBREW_ROOT=/home/leon/perl5/perlbrew
    PERLBREW_VERSION=0.25
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @nwc10

On Mon, Dec 19, 2011 at 04​:52​:52PM -0800, Leon Timmermans wrote​:

This means however that we have about 80 'X' symbols (exported but not
officially part of the API), without anyone realizing. This is a bad
thing IMO. On the short term, I would suggest moving them to a more

Agree.

visible place, though that requires either adding some logic to
makedef or dropping SFIO support.

If this is the tradeoff, then I think drop sfio support.

Does it even work still?
Does anyone use it?

I suspect that we do this by announcing as part of the 5.16 release notes
that we intend to do this (and why), proceed on the assumption that we're
going to get zero replies, and if anyone complains in years to come

a​: if it's about the lack of notice, point them at the relevant documentation
b​: if it's about the policy, ask them to help support it

This sort of approach (asking, but not trying *too* hard at asking) seems to
have worked quite well at getting rid of stuff before (eg suidperl. Zero
complaints on that one)

Nicholas Clark

The RT System itself - Status changed from 'new' to 'open'

From @Tux

On Tue, 20 Dec 2011 09​:10​:49 +0000, Nicholas Clark <nick@​ccl4.org>
wrote​:

On Mon, Dec 19, 2011 at 04​:52​:52PM -0800, Leon Timmermans wrote​:

This means however that we have about 80 'X' symbols (exported but not
officially part of the API), without anyone realizing. This is a bad
thing IMO. On the short term, I would suggest moving them to a more

Agree.

visible place, though that requires either adding some logic to
makedef or dropping SFIO support.

If this is the tradeoff, then I think drop sfio support.

+1

Does it even work still?
Does anyone use it?

I suspect that we do this by announcing as part of the 5.16 release notes
that we intend to do this (and why), proceed on the assumption that we're
going to get zero replies, and if anyone complains in years to come

a​: if it's about the lack of notice, point them at the relevant documentation
b​: if it's about the policy, ask them to help support it

This sort of approach (asking, but not trying *too* hard at asking) seems to
have worked quite well at getting rid of stuff before (eg suidperl. Zero
complaints on that one)

Nicholas Clark

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3.
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

From @rjbs

* Nicholas Clark <nick@​ccl4.org> [2011-12-20T04​:10​:49]

On Mon, Dec 19, 2011 at 04​:52​:52PM -0800, Leon Timmermans wrote​:
...

...
visible place, though that requires either adding some logic to
makedef or dropping SFIO support.

If this is the tradeoff, then I think drop sfio support.

Does it even work still?
Does anyone use it?

Phong Vo recently made the very generous offer to help us get it clearly
working again. This is obviously not to be taken lightly.

I've talked with a bunch of people off-list, but I think there are a few
questions we have to ask. The most important, and least specific is​:

* Is this worth fixing?

It's not just whether we'd like all the benefits of sfio. Of course we would.
There are other issues, though, which come out in more specific questions​:

* On how many platforms could we use sfio?
* Could we bundle sfio? (It looks license-incompatible from here.)
* How much extra effort would be required to maintain both sfio and stdio
  support?

I'm concerned that, getting sfio support back on track and building nicely, it
will be used only by a very small group and then fall quickly back into disuse.

But that's just me being a pessimist, and not being closely acquainted with the
specific technical issues here. Could someone(s) with an informed technical
perspective on this please comment?

Also, assuming there is no large chorus repeating that we should just drop sfio
support, volunteers to work on determining the specific sfio build problems
would be appreciated. ;)

--
rjbs

From @nwc10

On Fri, Dec 23, 2011 at 04​:15​:18PM -0500, Ricardo Signes wrote​:

* Nicholas Clark <nick@​ccl4.org> [2011-12-20T04​:10​:49]

On Mon, Dec 19, 2011 at 04​:52​:52PM -0800, Leon Timmermans wrote​:
...

...
visible place, though that requires either adding some logic to
makedef or dropping SFIO support.

If this is the tradeoff, then I think drop sfio support.

Does it even work still?
Does anyone use it?

"it" being the code in perl core that interfaces to sfio. Not sfio.

Phong Vo recently made the very generous offer to help us get it clearly
working again. This is obviously not to be taken lightly.

I've talked with a bunch of people off-list, but I think there are a few
questions we have to ask. The most important, and least specific is​:

* Is this worth fixing?

It's not just whether we'd like all the benefits of sfio. Of course we would.

What are the benefits to us of using sfio?

I have a rough idea of what the benefits are of using sfio instead of stdio.
But PerlIO isn't stdio. Parts of it layer on top of stdio. Parts of it talk
directly to Unix system calls and bypass stdio. And most of it is as
maintainable as the regular expression engine.

I don't *think* that using sfio lets us get rid of PerlIO. So I really don't
know what the answer is to my question.

* On how many platforms could we use sfio?
* Could we bundle sfio? (It looks license-incompatible from here.)

IIRC from 10 years ago, partial answers to those questions were

a​: not VMS, without it being ported
b​: No.
  And the then licence was unhelpful, in that whilst it permitted
  redistribution, it was worded such that indemnified AT&T from specific
  forms of legal attack, but not any downstream distributors.

I'm glad to see that the licence has changed, and that problem is gone.

It's not clear to me whether it's now possible for Perl to bundle it,
in that it's not obvious to me that http​://www.opensource.org/licenses/cpl
definitely contradicts GPL v2 or AL v1, nor is it obvious to me that it
would be compatible.

Nicholas Clark

From @Leont

On Fri, Dec 23, 2011 at 11​:15 PM, Ricardo Signes
<perl.p5p@​rjbs.manxome.org> wrote​:

Phong Vo recently made the very generous offer to help us get it clearly
working again.  This is obviously not to be taken lightly.

I've talked with a bunch of people off-list, but I think there are a few
questions we have to ask.  The most important, and least specific is​:

* Is this worth fixing?

It's not just whether we'd like all the benefits of sfio.  Of course we would.
There are other issues, though, which come out in more specific questions​:

* On how many platforms could we use sfio?
* Could we bundle sfio?  (It looks license-incompatible from here.)
* How much extra effort would be required to maintain both sfio and stdio
 support?

I'm concerned that, getting sfio support back on track and building nicely, it
will be used only by a very small group and then fall quickly back into disuse.

But that's just me being a pessimist, and not being closely acquainted with the
specific technical issues here.  Could someone(s) with an informed technical
perspective on this please comment?

Also, assuming there is no large chorus repeating that we should just drop sfio
support, volunteers to work on determining the specific sfio build problems
would be appreciated. ;)

Currently we support sfio (and stdio) *instead of* PerlIO. This is not
a sane thing to use (you'd lose important stuff like unicode support).
IMO we should get rid of this ASAP (or does microperl depend on
stdio?).

Adding an SFIO layer would be sane, and might actually be useful (for
starters, it's apparently thread-safe). It really shouldn't have to be
that hard either.

Leon

From @Leont

On Fri, Dec 23, 2011 at 11​:48 PM, Nicholas Clark <nick@​ccl4.org> wrote​:

I'm glad to see that the licence has changed, and that problem is gone.

It's not clear to me whether it's now possible for Perl to bundle it,
in that it's not obvious to me that http​://www.opensource.org/licenses/cpl
definitely contradicts GPL v2 or AL v1, nor is it obvious to me that it
would be compatible.

According to Wikipedia it is GPL incompatible, which is not
particularly helpful. I have no idea about the ALv1 though.

Leon