From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: libnettle/libhogweed WIP Date: Wed, 19 Apr 2017 09:38:50 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87lgqwsej9.fsf@lifelogs.com> References: <83a89gq3us.fsf@gnu.org> <87bmtjiv0w.fsf_-_@lifelogs.com> <83o9xjn06c.fsf@gnu.org> <87shmeb5ln.fsf_-_@lifelogs.com> <83y3w5z1ez.fsf@gnu.org> <87lgr6yakj.fsf@lifelogs.com> <87wpamww9k.fsf@lifelogs.com> <8337daggnj.fsf@gnu.org> <87d1cdwxt6.fsf@lifelogs.com> <83tw5pg1q3.fsf@gnu.org> <87zifhulc2.fsf@lifelogs.com> <83h91og80k.fsf@gnu.org> <87pogbuhoe.fsf@lifelogs.com> <834lxndmd9.fsf@gnu.org> <87efwrug6z.fsf@lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492612286 14503 195.159.176.226 (19 Apr 2017 14:31:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Apr 2017 14:31:26 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 19 16:31:21 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d0qdc-0003cU-6X for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 16:31:20 +0200 Original-Received: from localhost ([::1]:48469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0qdi-0006ve-2D for ged-emacs-devel@m.gmane.org; Wed, 19 Apr 2017 10:31:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d0qcp-0006tl-Jy for emacs-devel@gnu.org; Wed, 19 Apr 2017 10:30:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d0qcj-0004Nm-Aa for emacs-devel@gnu.org; Wed, 19 Apr 2017 10:30:31 -0400 Original-Received: from [195.159.176.226] (port=37180 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d0qcj-0004Kl-3G for emacs-devel@gnu.org; Wed, 19 Apr 2017 10:30:25 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1d0pop-0007aK-Ek for emacs-devel@gnu.org; Wed, 19 Apr 2017 15:38:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 28 Original-X-Complaints-To: usenet@blaine.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Cancel-Lock: sha1:W7SJ5oi6MN0uQpDOX1ZO3P70aO8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:214118 Archived-At: On Wed, 19 Apr 2017 08:22:10 -0400 Stefan Monnier wrote: >> I see the confusion. Yes, I want to allow multibyte input. Users >> shouldn't have to jump through hoops to use these functions. SM> FWIW, I disagree. You should check that either the string is unibyte SM> (AKA byte_size<0) or that it's ASCII-only (byte_size==size). SM> Forcing your users to (de|en)code explicitly before calling your SM> functions isn't making them jump through hoops: it's helping them have SM> the correct mental model of what "multibyte text" means. I think inside the Emacs environment, users won't care too much about the coding system or byte count, they'll just expect strings and buffers to work. But you're right that for interoperability with other tools and for file interactions, this is not trivial. And internally, I see it can't be assumed that the decrypted text will have the same coding system and unibyte/multibyte state as the original (this wasn't an issue with `secure-hash' since it only does digests). Since `secure-hash' supports multibyte in strings and buffers I think it makes sense to be consistent, and that's why I factored out extract_data_from_object(). So if we decide to make a change for how multibyte text is treated, let's do that consistently, thinking about interoperability and files, and consider the output as well. I think it will require a payload structure. What do you think? Ted