Re: Can .substring be made to handle an empty result?

[G. Branden Robinson]

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