New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
disallow literal control character variables #13144
Comments
From @rjbsThere are a bunch of variables in the form $^A, where A is some upper case say $^T; What's more, it's legal to put a literal ^T in the perl program: say $�; # <-- that's a literal ^T after the dollar sign there Why? So far, I have yet to find a great reason that it was allowed. It came use feature 'say'; This program prints: version v5.12.4 ...or... version v5.17.10 ...because, more or less, \cK is whitespace now. (This might not be exactly Rather than grump and blame EBCDIC, I think the solution is to call the literal This post is a duplicate of the initial non-perlbug suggestion: http://markmail.org/message/7zvlmra2y4r3d2hv -- |
From @TuxOn Thu, 01 Aug 2013 19:53:30 -0700, Ricardo SIGNES (via RT)
Fully support that deprecation. +1 from me
-- |
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn 08/02/2013 05:19 AM, H.Merijn Brand wrote:
+1 |
From @maukeOn 02.08.2013 04:53, Ricardo SIGNES (via RT) wrote:
This will break one of my programs. I say go for it :-) -- |
From @demerphq+1. On 2 August 2013 04:53, Ricardo SIGNES <perlbug-followup@perl.org> wrote:
-- |
From @HugmeirOn Thu, Aug 1, 2013 at 11:53 PM, Ricardo SIGNES
This branch implements the deprecation: https://github.com/Hugmeir/utf8mess/tree/disallow_cntrl It has a minor tweak to how S_scan_ident() skips over whitespace for Also, this required some changes to t/base/lex.t, which should make future |
From @cpansproutOn Sat Aug 31 09:25:37 2013, Hugmeir wrote:
Could you put that last paragraph in the commit message, too? (And, in Does the newline-skipping work outside of string eval? :-) -- Father Chrysostomos |
From @cpansproutOn Sat Aug 31 10:32:20 2013, sprout wrote:
Even if it doesn’t don’t worry about it, as I am in the middle of fixing -- Father Chrysostomos |
From @HugmeirOn Sat, Aug 31, 2013 at 2:32 PM, Father Chrysostomos via RT <
Sure, done.
Bugger, it doesn't do it properly -- ${\nfoo} doesn't warn about the \n |
From @cpansproutOn Sat Aug 31 11:16:34 2013, Hugmeir wrote:
And I’ve just discovered something else, too: $ ./perl -Ilib -le 'use Data::Dumper; ++$Data::Dumper::Useqq; print $ ./perl -Ilib -le 'use Data::Dumper; ++$Data::Dumper::Useqq; print Does your patch address that? Basically I’m writing ${^JOIN} (no such -- Father Chrysostomos |
From @HugmeirOn Sat, Aug 31, 2013 at 3:37 PM, Father Chrysostomos via RT <
Augh, that's nasty. I suspected something like that was possible but didn't $ ./perl -Ilib -le 'use Data::Dumper; ++$Data::Dumper::Useqq; print Dumper $ ./perl -Ilib -le 'use Data::Dumper; ++$Data::Dumper::Useqq; print Dumper Basically I’m writing ${^JOIN} (no such
|
From @nwc10On Sat Aug 31 09:25:37 2013, Hugmeir wrote:
Nice work. I don't think that it should be applied as-is, because:
That's this hunk? Inline Patchdiff --git a/toke.c b/toke.c
index 2764709..702f637 100644
--- a/toke.c
+++ b/toke.c
@@ -9340,7 +9340,7 @@ S_scan_ident(pTHX_ char *s, const char *send, char
@@ -9422,7 +9422,7 @@ S_scan_ident(pTHX_ char *s, const char *send, char - while (s < send && SPACE_OR_TAB(*s)) /* Expect to find a closing } after consuming any trailing I think that that should be its own commit (with a relevant test)
I think that your useful cleanup there should go in as its own commit Right now you have a single commit that is doing 3 things 1) cleaning up t/base/lex.t (with no functional changes) It would be lot clearer to split those 3 distinct things out. Also, right now, when I test your branch as-is, it's failing 1 test Thanks for tackling this. Nicholas Clark |
From @HugmeirOn Sun, Sep 1, 2013 at 4:53 AM, Nicholas Clark via RT <
Thank you for your review. This makes sense, apologies for the sloppy
This is what I get for rebasing the branch and not testing properly. This lead me to realize that this was broken: $ perl -e 'eval "\${\nfoo} = 10; warn q{should be line 2}"' Worse still, this branch broke that further if there were multiple newlines I have a fix for that (sorry, Father C! I hope there's no clashes. if there I've pushed that fix in the same branch, but perhaps it should go in a Additionally, with the above change, I think we could simplify But Karl should chime in for that one. In any case, those changes render the original test pointless, so I've |
From @cpansproutOn Sun Sep 01 16:51:23 2013, Hugmeir wrote:
The work I was referring to is in blead now. -- Father Chrysostomos |
From @nwc10On Sun, Sep 01, 2013 at 08:50:38PM -0300, Brian Fraser wrote:
You have this: Inline Patchdiff --git a/toke.c b/toke.c
index e125181..228fd12 100644
--- a/toke.c
+++ b/toke.c
@@ -3943,7 +3943,10 @@ S_intuit_more(pTHX_ char *s)
weight -= seen[un_char] * 10;
if (isWORDCHAR_lazy_if(s+1,UTF)) {
int len;
- scan_ident(s, send, tmpbuf, sizeof tmpbuf, FALSE);
+ char *tmp = PL_bufend;
+ PL_bufend = (char*)send;
+ scan_ident(s, tmpbuf, sizeof tmpbuf, FALSE);
+ PL_bufend = tmp;
len = (int)strlen(tmpbuf);
if (len > 1 && gv_fetchpvn_flags(tmpbuf, len,
UTF ? SVf_UTF8 : 0, SVt_PV)
I don't know. If I understand it correctly, your first 3 commits are related, e00d033 Reworked t/base/lex.t to use less hardcoded test numbers. But they are all dealing with the same thing, aren't they - whitespace and So they seem to fit just as well as 5 commits on the same branch, as a
Could you explain why? It's not obvious to me, and I guess to quite a few Nicholas Clark |
From @HugmeirOn Mon, Sep 2, 2013 at 12:28 PM, Nicholas Clark <nick@ccl4.org> wrote:
I think so. Mind you, I've been wrong before :) My understand is that This uses yyerror(): This uses croak():
Sure. 6a048a6 changed part of the definition of VALID_LEN_ONE_IDENT |
From @khwilliamsonOn Mon Sep 02 09:26:09 2013, Hugmeir wrote:
The reason for that cognitive load is entirely EBCDIC. It isn't that |
From @HugmeirOn Mon, Sep 2, 2013 at 2:44 PM, Karl Williamson via RT <
Aw, that's a shame. Thank you for the feedback. That aside, if there are no objections with the branch as-is, there's a |
From @cpansproutOn Sat Sep 14 19:24:17 2013, Hugmeir wrote:
One question: - while (s < PL_bufend && ( SPACE_OR_TAB(*s) || *s == '\n' )) Is while necessary there? Won’t if work?
Congratulations! A week from now, mine will be three years old. Are -- Father Chrysostomos |
From @HugmeirOn Sun, Sep 15, 2013 at 2:42 AM, Father Chrysostomos via RT <
It's not, cargo-culted that from the previous version; 'if' will work well.
|
From @jkeenanOn Sun Sep 15 12:05:22 2013, Hugmeir wrote:
Father C, hugmeir, khw: Can we get an update on the status of issues discussed in this ticket? Thank you very much. |
From @HugmeirOn Wed, Dec 11, 2013 at 11:27 PM, James E Keenan via RT <
Ah, thanks for following through! I forgot to mark this as resolved; The |
From @HugmeirMarking as resolved. --hugmeir |
@Hugmeir - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#119123 (status was 'resolved')
Searchable as RT119123$
The text was updated successfully, but these errors were encountered: