Front page | perl.perl5.porters |
Postings from July 2010
On Tue, Jul 13, 2010 at 01:11:11PM +0000, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Jul 13, 2010 at 11:43, Ben Morrow <ben@morrow.me.uk> wrote:
> > Perl doesn't have undefined behaviour. No matter what weasel words
> > copied from stdc made it into the ++ docs, Perl's actual evaluation
> > order has always been straightforward and well-defined. Changing this
> > may be worth it, for a sufficiently beneficial optimisation, but it is
> > definitely a backwards-incompatible change.
>
> Undefined doesn't mean that the implementation doesn't act
> consistently, just that its documentation explicitly denies
> responsibility for having those things work in the future. If they
> work now they only work incidentally, and you shouldn't rely on them.
http://www.lysator.liu.se/c/c-faq/c-5.html#5-23
Briefly: implementation-defined means that an implementation must choose
some behavior and document it. Unspecified means that an implementation
should choose some behavior, but need not document it. Undefined means
that absolutely anything might happen.
I suspect that all of our documentation should say "unspecified" rather than
"undefined".
> Of course we can't liberally change things that are documented to be
> undefined as liberally as a C compiler would, becuase there's only one
> perl(1) but multiple cc(1)'s.
But whatever we call it, that's the key problem. There is only one
implementation, and as that implementation strives hard to internally avoid
C undefined behaviour, its output will be deterministic, in some fashion.
Hence people come to rely on the current behaviour of the implementation,
documented or not.
Nicholas Clark
Thread Previous
|
Thread Next