bug#58446: 28.2; file-attribute-device-number returns a cons cell instead of an integer

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>>> - The name `file-attribute-file-number` doesn't sound right
>>>   because it doesn't return a number.
>> The name is a reminiscence of the existing variable buffer-file-number,
>> which serves exactly the same purpose.
>
> One error doesn't justify another.
> Maybe a better name would be "file identifier"?

True, but I'd let decide the maintainers.

>>> - I wouldn't use `defsubst` (so it can more easily be modified in the
>>>   future, e.g. in case we add more fields to the attributes or use some
>>>   other representation for attributes).
>> All other accessor functions for file-attributes are defsubsts.
>
> Every `defsubst` should be judged on its own individual value.
> This one doesn't seem to be justified.

As I said, it should be an "accessor function" for the result of
file-attributes. Just a stupid one, which returns inode and
device. That's the intention, and not something more sophisticated about
identifying a file.

>>> - I would document it more abstractly, mentioning inode and device
>>>   number only as *examples* of things it might contain.
>> There is no intention to use it for anything else.  It shall return
>> (nthcdr 10 attributes) like all the other file-attributes accessor
>> functions return for the respective slots.
>
> I did not suggest changing its implementation.  Only its documentation.
> The doc should describe the intended semantics of the return value
> without documenting how it's implemented.

The intended semantics is what's described. I understand that you see
something more for the future. I don't see it, sorry. No other use case
I could think of.

We have file-equal-p for more sophisticated checks, and this has even
file name handler support.

>         Stefan

Best regards, Michael.