-
Notifications
You must be signed in to change notification settings - Fork 42
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
Back references named "NIL" probably refer to unnamed registers. #12
Comments
nbtrap
added a commit
to nbtrap/cl-ppcre
that referenced
this issue
Jan 15, 2014
… "NIL". This fixes issue edicl#12. Back references referring to the register named "NIL" were being associated with the register with name NIL (the symbol) instead of "NIL" (the string). In this case NIL (symbol) is supposed to indicate that the register is unnamed, but this was not being checked with STRINGP before comparison with STRING=.
nbtrap
added a commit
to nbtrap/cl-ppcre
that referenced
this issue
Jan 16, 2014
… "NIL". This fixes issue edicl#12. Back references referring to the register named "NIL" were being associated with the register objects with NIL for their slot name (indicating an unnamed register) instead of those that actually have "NIL" (the string) for a name. One corollary of this patch is that back references may now refer to named registers using symbols in addition to strings. This is only consistent, since named registers may themselves be named from symbols. To put it another way: names are strings, but they may be represented in the parse tree with symbols.
nbtrap
added a commit
to nbtrap/cl-ppcre
that referenced
this issue
Jan 26, 2014
… "NIL". This fixes issue edicl#12. Back references referring to the register named "NIL" were being associated with the register objects with NIL for their NAME slot (indicating an unnamed register) instead of those that actually have "NIL" for a name. One corollary of this patch is that back references may now refer to named registers using symbols in addition to strings. This is only consistent, since named registers may themselves be named from symbols. To put it another way: names are strings, but they may be represented in the parse tree with symbols.
nbtrap
added a commit
to nbtrap/cl-ppcre
that referenced
this issue
Jan 26, 2014
… "NIL". This fixes issue edicl#12. Back references referring to the register named "NIL" were being associated with the register objects with NIL for their NAME slot (indicating an unnamed register) instead of those that actually have "NIL" for a name. One corollary of this patch is that back references may now refer to named registers using symbols in addition to strings. This is only consistent, since named registers may themselves be named from symbols. To put it another way: names are strings, but they may be represented in the parse tree with symbols.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Back references named "NIL" don't actually get associated with the register named "NIL" (at least not usually). In fact, they are often associated with unnamed registers. For example, the following match succeeds:
This is caused by comparing with STRING= without first confirming STRINGP.
I'll send in a fix for this shortly.
The text was updated successfully, but these errors were encountered: