Hi, Jim! At 2021-03-26T15:20:11-0700, Jim Avera wrote: > I'm trying to use .substring to remove the first character of a > string, leaving behind whatever follows, even if that is nothing (i.e. > the string had only one character). > > .substring str 1 > > or > > .length n2 "\*[str] > .nr n2 -1 > .substring str 1 \n[n2] > > (if n2 is omitted, it appears to default to length-1 as you might > expect). > > The above works as long as the string originally had at least two > characters. If it only has one, so the desired result is the empty > string, it does not remove anything, leaving behind the 0th character > and emitting a warning (with -w all). > > This seems like a corner-case bug.
Hmm, yes. I don't think groff's "slicing" operator is as rigorously defined as, say, Python's. > Question: Is this intentional, to remain "bug compatible" with some > older roff systems? I don't know if it was intentional, but if it was, then almost certainly not for the reason you speculate. groff, which began development in about 1989, is the first *roff I know of since Salzer's RUNOFF in the 1960s to support request lengths greater than two. In other words, no other troff had request called "substring". > At first glance, it seems like it would be safe to fix this because > the result is currently always wrong in this case, i.e. n1 equals the > length of the string (so the result should be empty). > > Thoughts? This seems like a valid request. We need (1) a unit test for the boundary conditions of the .substring request and (2) a precise description of its slicing semantics in our documentation. If groff's behavior must be changed for practicality or sanity reasons, we must also decide whether this case is significant enough to merit attention in our NEWS file for the next release. Can you file a Savannah ticket for this, please, Jim? Regards, Branden
signature.asc
Description: PGP signature
