Dear Manoj,
Thank you for your attention to this issue.
If the issue I reported is not a bug, then would you please be so kind as to
explain to me what the regular expression sequence in question is meant to
match?
I recognize that this portion of the manual is correct:
" A.4.1 Numbers
C99 decimal constant
([[:digit:]]{-}[0])[[:digit:]]*
C99 hexadecimal constant
0[xX][[:xdigit:]]+
C99 octal constant
0[01234567]* "
The part I do not understand is the indicated portion of this snippet:
^
" A.4.3 Quoted Constructs
C99 String Literal
L?\"([^\"\\\n]|(\\[’\"?\\abfnrtv])|(\\([0123456]{1,3}))|(\\x[[:xdigit:]]+)|(\\u([[:
--truncated-- "
^^
I believe this portion of the regular expression matches a back-slash followed
by 1, 2, or 3 digits in the range 0-6. Given that the next portion matches a
back-slash followed by an “x” followed by one or more hexadecimal digits,
representing literal string characters, this strongly suggests to me that the
indicated portion is supposed to match the octal representation of literal
string characters. If this is not what it is, then what is it?
I repeat that I believe this is a bug, and that the indicated set should
include the digit “7” along with the digits 0-6.
I look forward to your further reply.
Best regards,
Paul Rolig
-Original Message-
From: Manoj Srivastava [mailto:sriva...@acm.org]
Sent: Saturday, February 13, 2016 8:36 PM
To: Paul Rolig
Cc: 755...@bugs.debian.org; cont...@bugs.debian.org
Subject: Re: Bug#755137: Substantive typo in 'flex' manual C99 String Literal
severity 755137 minor
thanks
On Thu, Jul 17 2014, Paul Rolig wrote:
> Package: flex
> Version: 2.5.37
>
> In the example regular expression for C99 String Literal, about 1/3 of
> the way from the left is the set '[0123456]'. Presumably, this is
> intended to match escaped octal numeric literals, in which case the
> digit '7' should also be included in the set.
It is not meant to be the octal numerals. There is a different regular
expression a little before that which is the proper one to use.
> this same example C99 String Literal example regular expression
> suffers the same omission as above,
This is not a bug.
> and also is truncated on the right
> where it extends beyond the edge of the page. (125 is the page number
> printed at the top of the page, but it is the 132nd page in the PDF
> file.)
The overflows are a bug, indeed, but the info manual is fine. I am
lowering the severity of this report, but I’ll work the issue.
manoj
--
Live long and prosper. Spock, "Amok Time", stardate 3372.7 Manoj Srivastava
<sriva...@acm.org> <http://www.golden-gryphon.com/> 4096R/C5779A1C E37E 5EC5
2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
