GNU bug report logs - #56641
Deprecate `lsh`

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com, 56641 <at> debbugs.gnu.org
Subject: bug#56641: Deprecate `lsh`
Date: Wed, 20 Jul 2022 16:30:25 +0200

20 juli 2022 kl. 14.21 skrev Po Lu <luangruo <at> yahoo.com>:

> So you're saying there is no possible use for expecting the value of
> this:
> 
>  (lsh most-negative-fixnum -1)
> 
> to become:
> 
>  #x1000000000000000

That is only true when Emacs has been built for 62-bit fixnums. And no, I don't see an obvious use other than for compatibility.

> What business does the byte compiler, or some idea
> of "platform independence" have in dictating that I should write extra
> code (instead of using something built-in) to implement a network
> protocol?

It sounds as if we are talking past one another. If you have a network protocol that is somehow defined in terms of the size of fixnums in a particular build of Emacs, then yes, I'd say that most people would think that your code should make that explicit.

But you certainly don't need lsh to handle arbitrary binary data; it's not even convenient. I'm not saying that you are wrong; perhaps I don't understand your needs.

We could add functions for depositing and extracting bit fields in an integer, basically encapsulating the common shift-and-mask operations. That would make bit field manipulation less error-prone without compromising speed or portability.

Previous Next

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