GNU bug report logs - #48960
stat v8.30 - device number in decimal shown as 16bit number instead of to converted 8bit

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48960 in the body.
You can then email your comments to 48960 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Wolfgang Rohm <wolfgang.rohm <at> arcor.de>
To: bug-coreutils <at> gnu.org
Subject: stat v8.30 - device number in decimal shown as 16bit number instead
 of to converted 8bit
Date: Fri, 11 Jun 2021 09:37:54 +0200

[Message part 1 (text/plain, inline)]

Hello.

Stat prints the device number, major and minor, in hex and decimal. They 
are both 8bit numbers clamped together. While the hex number is 
perfectly fine, the decimal doesn't respect how this number has come to 
existence. There is no meaning in the decimal value, if the the hex 
value is taken as one 16bit number and then converted.

For example "fd00h" is converted to "64768d". There is no major device 
with 647 and no minor device with 768. Its just completely wrong.

So instead of converting fd00h to 64768d, both 8bit hex numbers must be 
converted each, meaning alone. The right number would be therefore 
253000, major 253 and minor 0. While the hex number needs two digits 
each (the first 0 can be ommited), the decimal needs three digits each 
(the first and second 0 can be omitted).

|stat (GNU coreutils) 8.30
Copyright © 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Geschrieben von Michael Meskes.
|

-- 
Mit freundlichen Grüßen
Wolfgang Rohm

[Message part 2 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: wolfgang.rohm <at> arcor.de, 48960 <at> debbugs.gnu.org
Subject: Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit
 number instead of to converted 8bit
Date: Fri, 11 Jun 2021 10:11:15 -0700

The stat output is confusing in other ways. For example:

507-day $ ls -ld .; stat . | grep Device
drwxr-xr-x 4 eggert eggert 12288 May  5 14:48 .
Device: 10300h/66304d	Inode: 70388429    Links: 4
508-day $ ls -ld /dev/ptp0; stat /dev/ptp0 | grep Device
crw------- 1 root root 246, 0 Jun  3 13:09 /dev/ptp0
Device: 5h/5d	Inode: 321         Links: 1     Device type: f6,0

As you write, that "66304d" is useless on my platform, and the "5h/5d" 
uses a completely different notation from the "f6,0".

I suggest that we change the behavior of both "Device:" and "Device 
type:" to be consistent with that of 'ls', so that the output becomes:

507-day $ ls -ld .; stat . | grep Device
drwxr-xr-x 4 eggert eggert 12288 May  5 14:48 .
Device: 259, 0	Inode: 70388429    Links: 4
508-day $ ls -ld /dev/ptp0; stat /dev/ptp0 | grep Device
crw------- 1 root root 246, 0 Jun  3 13:09 /dev/ptp0
Device: 0, 5	Inode: 321         Links: 1     Device type: 246, 0

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

From: L A Walsh <coreutils <at> tlinx.org>
To: Wolfgang Rohm <wolfgang.rohm <at> arcor.de>
Cc: 48960 <at> debbugs.gnu.org
Subject: Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit
 number instead of to converted 8bit
Date: Fri, 11 Jun 2021 11:21:04 -0700

On 2021/06/11 00:37, Wolfgang Rohm wrote:
> Hello.
>
> Stat prints the device number, major and minor, in hex and decimal. 
> They are both 8bit numbers clamped together. While the hex number is 
> perfectly fine, the decimal doesn't respect how this number has come 
> to existence. There is no meaning in the decimal value, if the the hex 
> value is taken as one 16bit number and then converted.
>
> For example "fd00h" is converted to "64768d". There is no major device 
> with 647 and no minor device with 768. Its just completely wrong.
---
   Aside from complete bogus output on my system for either
hex or decimal and the "seemingly" undocumented appearance of 'd'
to convert a 16-bit decimal value back to 2 8-bit values
divide the number by 256 or shift the value right by 8 bits
for the high number and either mod the number with 256 or
'and' (&) the value with 0xff:

decimal_devno=64768   #(dropping the 'd' on the end)
high=$(($decimal_devno/256))
low=$(($decimal_devno%256))
printf "%s:%s\n" "$high" "$low"

 (output:)
253:0

 or via shifts+masks

decimal_devno=64768
high=$((decimal_devno>>8))
low=$((decimal_devno & 0xff))
printf "%s:%s\n" "$high" "$low"

 (output:)
253:0

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, wolfgang.rohm <at> arcor.de,
 48960 <at> debbugs.gnu.org
Subject: Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit
 number instead of to converted 8bit
Date: Sat, 12 Jun 2021 16:19:28 +0100

On 11/06/2021 18:11, Paul Eggert wrote:
> The stat output is confusing in other ways. For example:
> 
> 507-day $ ls -ld .; stat . | grep Device
> drwxr-xr-x 4 eggert eggert 12288 May  5 14:48 .
> Device: 10300h/66304d	Inode: 70388429    Links: 4
> 508-day $ ls -ld /dev/ptp0; stat /dev/ptp0 | grep Device
> crw------- 1 root root 246, 0 Jun  3 13:09 /dev/ptp0
> Device: 5h/5d	Inode: 321         Links: 1     Device type: f6,0
> 
> As you write, that "66304d" is useless on my platform, and the "5h/5d"
> uses a completely different notation from the "f6,0".
> 
> I suggest that we change the behavior of both "Device:" and "Device
> type:" to be consistent with that of 'ls', so that the output becomes:
> 
> 507-day $ ls -ld .; stat . | grep Device
> drwxr-xr-x 4 eggert eggert 12288 May  5 14:48 .
> Device: 259, 0	Inode: 70388429    Links: 4
> 508-day $ ls -ld /dev/ptp0; stat /dev/ptp0 | grep Device
> crw------- 1 root root 246, 0 Jun  3 13:09 /dev/ptp0
> Device: 0, 5	Inode: 321         Links: 1     Device type: 246, 0

Yes I agree with this.
I.e. it's most useful to present decomposed decimal IDs.

What we have now in format specifiers is also inconsistent/incomplete:

 %d     (composed) device number in decimal (st_dev)
 %D     (composed) device number in hex (st_dev)
 %t     major device type in hex, for device special files (st_rdev)
 %T     minor device type in hex, for device special files (st_rdev)

I.e. no decomposed st_dev, or no decimal st_rdev.
I think it's more important to provide decomposed numbers,
rather than hex representations (especially decomposed hex).
It's probably best not to change any of the above format specifiers though
for compat reasons. %d while not that useful in isolation, may be used
to distinguish files or devices, which might be persisted in manifests etc.

We could take the FreeBSD approach which is:

  %Hd  major device number in decimal (st_dev)
  %Ld  minor device number in decimal (st_dev)
  %Hr  major device type in decimal (st_rdev)
  %Lr  minor device type in decimal (st_rdev)

Note I'd be inclined to not have a space between major,minor in default stat output,
as there should be no ambiguity with locale formatted numbers, which could be
the case with ls. For example, my ls alias uses thousands grouping with:
alias ls="BLOCK_SIZE=\'1 ls --color=auto".
I.e. the default format would from stat would be
Device: %Hd,%Ld  ..... Device type: %Hr,%Lr

For consistency if we provided the above we should also probably provide:

 %r     (composed) device type in decimal (st_rdev)
 %R     (composed) device type in hex (st_rdev)

cheers,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, wolfgang.rohm <at> arcor.de,
 48960 <at> debbugs.gnu.org
Subject: Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit
 number instead of to converted 8bit
Date: Sun, 20 Jun 2021 15:21:54 +0100

[Message part 1 (text/plain, inline)]

On 12/06/2021 16:19, Pádraig Brady wrote:
> We could take the FreeBSD approach which is:
> 
>     %Hd  major device number in decimal (st_dev)
>     %Ld  minor device number in decimal (st_dev)
>     %Hr  major device type in decimal (st_rdev)
>     %Lr  minor device type in decimal (st_rdev)
> 
> Note I'd be inclined to not have a space between major,minor in default stat output,
> as there should be no ambiguity with locale formatted numbers, which could be
> the case with ls. For example, my ls alias uses thousands grouping with:
> alias ls="BLOCK_SIZE=\'1 ls --color=auto".
> I.e. the default format would from stat would be
> Device: %Hd,%Ld  ..... Device type: %Hr,%Lr
> 
> For consistency if we provided the above we should also probably provide:
> 
>    %r     (composed) device type in decimal (st_rdev)
>    %R     (composed) device type in hex (st_rdev)

The attached adds the new formats.
I'll follow up with another to adjust the default output accordingly.

cheers,
Pádraig

[stat-device-formats.diff (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 wolfgang.rohm <at> arcor.de, 48960 <at> debbugs.gnu.org
Subject: Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit
 number instead of to converted 8bit
Date: Sun, 20 Jun 2021 14:38:01 -0700

Thanks for writing that patch. One minor note:

On 6/20/21 7:21 AM, Pádraig Brady wrote:

> +                                    (to_uchar (mod_char) << CHAR_BIT)
> +                                     + to_uchar (fmt_char),

Neither mod_char nor fmt_char can be negative (this is guaranteed by the 
C standard since all the relevant constants are in the basic character 
set) so the to_uchar calls are unnecessary.

Also, this code assumes that 2 * CHAR_BIT <= MIN (INT_WIDTH, 
UINT_WIDTH), something that POSIX requires but the C standard does not; 
it'd be a bit safer (if pedantic) to add 'verify (2 * CHAR_BIT <= MIN 
(INT_WIDTH, UINT_WIDTH));'.

I'd also change print_stat's arg from unsigned int to int; if you did 
that, you could change the above 'MIN (INT_WIDTH, UINT_WIDTH)' to plain 
'INT_WIDTH'. (These days we're negative on unsigned types anyway, for 
all the usual reasons....)

Better yet, pass two char args to print_stat instead of a single int 
portmanteau.

Message #25 received at 48960-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, wolfgang.rohm <at> arcor.de,
 48960-done <at> debbugs.gnu.org
Subject: Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit
 number instead of to converted 8bit
Date: Mon, 21 Jun 2021 12:07:01 +0100

On 20/06/2021 22:38, Paul Eggert wrote:
> Thanks for writing that patch. One minor note:
> 
> On 6/20/21 7:21 AM, Pádraig Brady wrote:
> 
>> +                                    (to_uchar (mod_char) << CHAR_BIT)
>> +                                     + to_uchar (fmt_char),
> 
> Neither mod_char nor fmt_char can be negative (this is guaranteed by the
> C standard since all the relevant constants are in the basic character
> set) so the to_uchar calls are unnecessary.
> 
> Also, this code assumes that 2 * CHAR_BIT <= MIN (INT_WIDTH,
> UINT_WIDTH), something that POSIX requires but the C standard does not;
> it'd be a bit safer (if pedantic) to add 'verify (2 * CHAR_BIT <= MIN
> (INT_WIDTH, UINT_WIDTH));'.
> 
> I'd also change print_stat's arg from unsigned int to int; if you did
> that, you could change the above 'MIN (INT_WIDTH, UINT_WIDTH)' to plain
> 'INT_WIDTH'. (These days we're negative on unsigned types anyway, for
> all the usual reasons....)
> 
> Better yet, pass two char args to print_stat instead of a single int
> portmanteau.

Yes two separate char arguments is cleaner.
I thought there was some reason for the existing unsigned int usage,
but looking I see it was added for commit db42ae78 (to support :X formats),
but then became unneeded with commit c7375c23 (to instead support %.9X formats).

I've pushed both commits now, so marking this as done,

thanks for the review!
Pádraig

Previous Next

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