[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tramp and fixnum (was: Making 'eq' == 'eql' in bignum branch)

From: Paul Eggert
Subject: Re: Tramp and fixnum (was: Making 'eq' == 'eql' in bignum branch)
Date: Sun, 26 Aug 2018 08:34:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Michael Albinus wrote:

* net/tramp-sh.el contains some assumptions that file sizes and other
attributes that don't fit into fixnums are converted to floats by the
underlying drivers. This assumption won't be true of list-attributes,
and presumably shouldn't be true of tramp's other drivers (though I
don't know the details here; I'm handwaving a bit).

Could you pls explain in more detail what you believe is wrong? A
pointer to a suspicious code snippet would help.

What do you mean with `list-attributes'? Maybe `file-attributes'?

Yes, sorry, I meant 'file-attributes'. The fishy-looking code is in tramp-convert-file-attributes. Here's one snippet:

    (when (and (floatp (nth 2 attr))
               (<= (nth 2 attr) most-positive-fixnum))
      (setcar (nthcdr 2 attr) (round (nth 2 attr))))

Although this snippet shouldn't hurt, it should be unnecessary once file-attributes is fixed to not return floats. And in the meantime, the "(<= (nth 2 attr) most-positive-fixnum)" is unnecessary since file-attributes never returns a float less than or equal to most-positive-fixnum. There are three snippets like this.

The main offender is the inode converter in that function, which splits integers into three parts, whereas it should simply keep the integers as-is since they don't overflow any more.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]