GNU bug report logs -
#48960
stat v8.30 - device number in decimal shown as 16bit number instead of to converted 8bit
Previous Next
Reported by: wolfgang.rohm <at> arcor.de
Date: Fri, 11 Jun 2021 14:58:03 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 21 Jun 2021 12:07:01 +0100
with message-id <d89bc49b-901f-0947-316d-e38a5dd324fd <at> draigBrady.com>
and subject line Re: bug#48960: stat v8.30 - device number in decimal shown as 16bit number instead of to converted 8bit
has caused the debbugs.gnu.org bug report #48960,
regarding stat v8.30 - device number in decimal shown as 16bit number instead of to converted 8bit
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
48960: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=48960
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (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 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
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
This bug report was last modified 3 years and 340 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.