GNU bug report logs - #77387
[PATCH 0/2] man-db: Better parsing of man macros.

Previous Next

Full log

Message #38 received at 77387 <at> debbugs.gnu.org (full text, mbox):

From: Sergey Trofimov <sarg <at> sarg.org.ru>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, 77387 <at> debbugs.gnu.org,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Christopher Baines <guix <at> cbaines.net>
Subject: Re: [bug#77387] [PATCH 1/2] man-db: Parse man macro arguments better.
Date: Wed, 09 Apr 2025 14:59:55 +0200

Hi,

Ludovic Courtès <ludo <at> gnu.org> writes:
>>>> +             (in-string? #f))
>>>> +    (if (>= pos (string-length input))
>>>> +        ;; End of input
>>>> +        (unless in-string?
>>>> +          (reverse (if (null? current)
>>>> +                       tokens
>>>> +                       (cons (list->string (reverse current)) tokens))))
>>>
>>> So this procedure can return *unspecified*, right?  Sounds fishy.
>>>
>> Why is it fishy? Is it unconventional? Such return value is handled
>> correctly by the calling code (`match`).
>
> It’s unconventional; usually, procedures are monomorphic and in this
> case, the expectation is that it always returns a list of tokens.
>
> I would either return the empty list in the ‘in-string?’ case or throw
> an exception (because that means we failed to parse the thing).
>
> Does that make sense?

I wouldn't throw an exception as this would break the derivation
building an consequently profile switch. I've removed the offending
`unless` altogether. `man` itself seem to be forgiving for such syntax
violations.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.