Re: string comparison bug in pic

"G. Branden Robinson" <[email protected]> Sat, 3 Jan 2026 03:43:04 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260103094304.thlrd3af54wuwnp6@illithid>
Hi Doug,

At 2026-01-02T21:19:34-0500, Douglas McIlroy wrote:
> In pic 1.23.0 string comparison doesn't work at the top level of
> print.  These  statements are accepted
>       x = "a"=="a"
>       print ("a"=="a")
> This is not accepted
>       print "a"=="a"

Agreed.  I can reproduce this with groff Git HEAD, 1.23.0, 1.22.4, and
1.22.3.  It's likely been the case for many years.

To be more precise, for me the first "a" in `print "a"=="a"` gets
printed, and then the syntax error is thrown.

Apparently the grammar for "print" as implemented, if it sees a string
literal, demands _only_ that and not a more complex expression.  Could
be an error or oversight in the YACC grammar.

> I don't see this mentioned in
> https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS. Should I
> file a bug report?

Yes, I think so.  Our pic(1) man page documents "print" as a GNU
extension, so we'll need to decide whether this is a defect or a feature
change.

It might be the latter if we have to revise the grammar.  For instance I
can imagine that the existing one has productions like this:

PRINT arithmetic-expression
PRINT string-literal

where "arithmetic-expression" cannot start with a '"'.

Maybe we need a new production rule, something like this:

PRINT string-expression

...and to define the nonterminal "string-expression" accordingly.

I observe that the pic(1) input:

a = "mystring";

...is also a syntax error and, I presume, not a surprise to an
experienced pic user.

If I'm correct, I infer that the production

ASSIGN variable = string-literal

--or however one is supposed to say that properly, since like Microsoft
BASIC, the symbol for an assignment or "LET" terminal can be null/
epsilon--does not exist in GNU pic.

> Puzzlingly, the NEWS file dubs several features that were already in
> pic 1.23.0 as "new". The NEWS doesn't actually say which version it
> pertains to.

If you're looking at the same file I am:

https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0

...then the heading for 1.23.0 news items starts on line 10.

The items for the immediately previous release don't start until line
692.  1.23.0 was, uh, kind of a big release.

Can you clarify?  Did ~700 lines of 1.23 news stun you into overlooking
the heading for 1.22.4?  Is your copy of the file corrupt?  I have the
following.

$ git checkout 1.23.0
$ cksum NEWS
1077560524 127779 NEWS

As I noted yesterday, we have about 912 lines of news items for groff
1.24.0,[1] and that's _before_ I add entries for some of the PDF feature
support Deri's added in the past 2½ years.[2]

Regards,
Branden

[1] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n12
[2] https://savannah.gnu.org/bugs/?66452
    https://savannah.gnu.org/bugs/?66453
signature.asc (application/pgp-signature, 833 B)