unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattiase@acm.org>
To: Po Lu <luangruo@yahoo.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	stefankangas@gmail.com, 56641@debbugs.gnu.org
Subject: bug#56641: Deprecate `lsh`
Date: Wed, 20 Jul 2022 16:30:25 +0200	[thread overview]
Message-ID: <F6FCCE3D-CE62-4E89-9C0B-8A32A97A074A@acm.org> (raw)
In-Reply-To: <87k0889dp4.fsf@yahoo.com>

20 juli 2022 kl. 14.21 skrev Po Lu <luangruo@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.






  parent reply	other threads:[~2022-07-20 14:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 13:38 bug#56641: Deprecate `lsh` Mattias Engdegård
2022-07-19 13:52 ` Eli Zaretskii
2022-07-19 14:44   ` Stefan Kangas
2022-07-19 15:40     ` Eli Zaretskii
2022-07-19 15:53     ` Mattias Engdegård
2022-07-19 16:20       ` Stefan Kangas
2022-07-19 16:38         ` Eli Zaretskii
2022-07-20  1:25           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20  2:36             ` Eli Zaretskii
2022-07-20  3:20               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 11:24                 ` Eli Zaretskii
2022-07-20 11:57                 ` Mattias Engdegård
2022-07-20 12:21                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-20 12:44                     ` Eli Zaretskii
2022-07-20 14:30                     ` Mattias Engdegård [this message]
2022-07-21  1:43                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-21  7:47                         ` Mattias Engdegård
2022-07-23  7:26 ` Lars Ingebrigtsen
2022-07-23 10:32   ` Mattias Engdegård
2022-07-23 11:20     ` Lars Ingebrigtsen
2022-07-23 13:18       ` Eli Zaretskii
2022-07-23 13:20         ` Lars Ingebrigtsen
2022-07-23 15:42     ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-23 16:51       ` Mattias Engdegård
2022-07-24  3:38         ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F6FCCE3D-CE62-4E89-9C0B-8A32A97A074A@acm.org \
    --to=mattiase@acm.org \
    --cc=56641@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).