GNU bug report logs - #76070
Subject: seq, hexadecimal args and equal width

Previous Next

Package: coreutils;

Reported by: Alexandre Lacoste <a.lacoste.r1996 <at> gmail.com>

Date: Wed, 5 Feb 2025 14:47:02 UTC

Severity: normal

Full log


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

From: Alexandre Lacoste <a.lacoste.r1996 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Subject: seq, hexadecimal args and equal width
Date: Wed, 5 Feb 2025 12:28:18 +0100
[Message part 1 (text/plain, inline)]
 There is a bug in seq. The equal-width option does not work with
hexadecimal arguments. For example:

$❯ seq -w 0x02 0x01 0x10
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$> seq -w 0x09.1 0.1 0x10
9,0625
9,1625
9,2625
9,3625
9,4625
9,5625
9,6625
9,7625
9,8625
9,9625
10,0625
10,1625
10,2625
10,3625
...
...
...

In the scan_arg function, ret.width is always set to 0 when the argument
is hexadecimal. Hexadecimal numbers are excluded on purpose, by this if:

    seq.c:181:  if (! arg[strcspn (arg, "xX")] && isfinite (ret.value))

This causes that for both integer and floating-point hexadecimal numbers,
only the default width and precision are assigned. As a result, later in
the 'get_default_format' function, this if condition is never entered:

    seq.c:371:  if (prec != INT_MAX && last.precision != INT_MAX)

Resulting in an output format of different width.

As a solution to this problem, I recommend modifying the scan_arg function
to also consider cases with hexadecimal (whether integer or floating-point
hexadecimal) in order to assign them the corresponding width and precision
values. That is the source of the issue.

I hope we can find a suitable solution soon. It is a pleasure to help. Best
regards!
[Message part 2 (text/html, inline)]

This bug report was last modified 136 days ago.

Previous Next


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