Front page | perl.perl5.porters |
Postings from September 2011
Re: The future of POSIX in core
Thread Previous
|
Thread Next
From:
Abigail
Date:
September 2, 2011 07:08
Subject:
Re: The future of POSIX in core
Message ID:
20110902140808.GA28754@almanda
On Fri, Sep 02, 2011 at 08:06:16AM -0400, David Golden wrote:
> On Fri, Sep 2, 2011 at 7:47 AM, Mark Overmeer <mark@overmeer.net> wrote:
> >> After you first raised the issue, Aristotle had also offered patches to do
> >> this alone [no prototype changes, same usage() checking]. I wrote quite a
> >> lot of tests, and rejigged and applied his patches, because there seemed to
> >> be consensus that you're dead right on this one, and his code offered a very
> >> elegant solution to just this.
> >
> > Yeh, I wondered why he got away with it so easily, where my patches
> > got totally ignored (what later got explained as "too late"). There are
> > some changes in the output produced by that change and no-one seems to
> > be bothered by that.
>
> There was a very real timing issue in that Jan/Feb/March is when the
> feature freeze for the next major release of Perl happens. Anything
> sweeping is unlikely to make it in at that point.
>
> As a separate note, I think you did yourself a dis-service by sending
> the four patches in one because it increases the scope. If you had
> submitted just the autosplit fix patch or re-submitted that one right
> after the release of 5.14, I think it would have stood a bigger chance
> of acceptance.
>
> Please remember that people applying patches are essentially vouching
> for the work of others and have a sense of accountability about what
> things they accept. (At least I hope they do). The harder you make
> that, the less likely thing are to be applied. That's even true of a
> patch series where now a patch appliers has to make a distinction
> between patches and enter into a debate over why some patches but not
> others are acceptable. Not everyone is willing to take on that
> responsibility all the time.
>
> >> > 3. remove documentation for all functions which are not really
> >> > implemented or documented as not possible to implement.
> >>
> >> Remove totally? Or document a list of "not really implemented" and
> >> "not possible to implement"
> >
> > You may write documentation about everything what is *not* possible
> > with Perl, but it is kind-of useless. Removing those from the docs fits
> > better in the idea of "keeping Perl core as small as possible". And the
> > documented list of "missing" is far from complete anyway.
>
> Once documented, it should stay documented.
>
> > tolower This is identical to the C function, except that it can apply
> > to a single character or to a whole string. Consider using the
> > "lc()" function, see "lc" in perlfunc, or the equivalent "\L"
> > operator inside doublequotish strings.
> >
> > "This is identical, *but*". The ctype/tolower *macro* can only handle
> > native characters. POSIX::tolower takes any string containing scalar,
> > ignores whether it is utf8 or not, and then treats all bytes in it as
> > 7-bit characters (ascii or ebcdic), returning a new scalar with the result.
> > We do not have a single character data-type in Perl.
> >
> > Let's asume that we are not implementing the programming language C. Then,
> > the documentation should, IMO, be reduced into:
> >
> > Legacy functions:
> > tolower use build-in funtion lc()
>
> This is a better example of where the existing POSIX functions should
> probably warn and the documentation is best revised to say "don't use
> this, use this other thing instead". I'm supportive of this kind of
> change.
I'm not. There will be two kinds of people who use that function: those
for whom it returns the wrong result, and those for whom it just works.
The first group is likely to find out something is wrong, even without
a warning, and for the second group, additional warnings are just a PITA.
In many aspects, adding a warning *IS* breakage.
> > Abigail did earlier protest against this change for a more valid reason:
> > POSIX functions have no prototype. So, in reality, these two programs
> > do differ now-adays:
> >
> > program 1:
> > use POSIX 'exit';
> > exit @rc;
> >
> > program 2:
> > exit @rc;
> >
> > I consider the situation a bug, in both cases, because the documentation
> > says that exit needs a scalar. But those bugs may show up with people.
>
> Ugh. I'm on the fence about this sort of change.
I don't think "needs a scalar" actually means "will not accept an array as
argument".
In fact, I consider the bug here to be:
$ perl -wE '@a = 2; exit @a; echo $?'
1
I actually expect this to print 2, and checking the manual page for exit,
there's actually nothing in it that suggests it's evaluating its argument
list in scalar context. Not only doesn't it say "needs a scalar", it doesn't
even mention the word "scalar":
=item exit EXPR
X<exit> X<terminate> X<abort>
=item exit
Evaluates EXPR and exits immediately with that value. Example:
$ans = <STDIN>;
exit 0 if $ans =~ /^[Xx]/;
See also C<die>. If EXPR is omitted, exits with C<0> status. The only
universally recognized values for EXPR are C<0> for success and C<1>
for error; other values are subject to interpretation depending on the
environment in which the Perl program is running. For example, exiting
69 (EX_UNAVAILABLE) from a I<sendmail> incoming-mail filter will cause
the mailer to return the item undelivered, but that's not true everywhere.
Don't use C<exit> to abort a subroutine if there's any chance that
someone might want to trap whatever error happened. Use C<die> instead,
which can be trapped by an C<eval>.
The exit() function does not always exit immediately. It calls any
defined C<END> routines first, but these C<END> routines may not
themselves abort the exit. Likewise any object destructors that need to
be called are called before the real exit. C<END> routines and destructors
can change the exit status by modifying C<$?>. If this is a problem, you
can call C<POSIX:_exit($status)> to avoid END and destructor processing.
See L<perlmod> for details.
Portability issues: L<perlport/exit>.
Abigail
Thread Previous
|
Thread Next