Front page | perl.perl5.porters |
Postings from January 2005
In article <rt-3.0.11-33689-105251.18.5910147079742@perl.org>,
Nicholas Clark (via RT) <perlbug-followup@perl.org> writes:
> # New Ticket Created by Nicholas Clark
> # Please include the string: [perl #33689]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33689 >
>
>
> This is a bug report for perl from nick@ccl4.org,
> generated with the help of perlbug 1.26 running under perl 5.008004.
>
>
> -----------------------------------------------------------------
> [Please enter your report here]
>
> Perl is consistently very proud that it can handle NUL bytes within data
> without flinching. However, variable names can't have NUL bytes in them.
> There's no underlying reason why they couldn't, because the hashes used to
> store variables names can store embedded NUL byes. However, it seems that
> variable names are always passed around internally as NUL terminated
> C strings (eg Perl_gv_fetchpv).
>
PS, two other places where perl can get confused by \0:
- The class you bless something into.
e.g. perl -wle 'print ref(bless [], "abcd\0efgh")'
- $@. ERRSV is handled as string too often,
e.g perl -wle 'sub DESTROY { die "ab\0cd" } bless []'
Thread Previous
|
Thread Next