From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 22 Nov 2015 19:17:03 +0000 Message-ID: References: <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <564E6081.9010805@cs.ucla.edu> <564E6352.20701@cs.ucla.edu> <564F86FF.6030202@cs.ucla.edu> <564FA768.40504@cs.ucla.edu> <5650FD75.5030707@cs.ucla.edu> <56520B83.6070302@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114450c8b4ae26052525f48d X-Trace: ger.gmane.org 1448219854 19912 80.91.229.3 (22 Nov 2015 19:17:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 19:17:34 +0000 (UTC) Cc: Daniel Colascione , Emacs developers To: Paul Eggert , Eli Zaretskii , Ted Zlatanov , =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 20:17:33 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0a8h-0001Ai-QC for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 20:17:32 +0100 Original-Received: from localhost ([::1]:57162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0a8h-000063-PC for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 14:17:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0a8S-00005K-Lf for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:17:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0a8R-0004tx-Id for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:17:16 -0500 Original-Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:37414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0a8P-0004ti-LZ; Sun, 22 Nov 2015 14:17:13 -0500 Original-Received: by wmww144 with SMTP id w144so80009220wmw.0; Sun, 22 Nov 2015 11:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=+P8BKM3P7IU/z5aJj7IigN29CNq4kOJ2lTSdVdmTGpY=; b=EpOMZx4x315uz8OVHZzf8biV23xNGExiytqNBTNjM5Bz77WZMfH7yI+fvnu+f2wI9y 7V0ubQ3zVBg+1j1Yp1wEr0AB++8ZRrlAbJK8oyDQ4XZJLtckGPRbE95qT3yTvUv/N5ti gJez9WiAyktGjsK06SPjQLnEHTTq+9I8hYGNaI2LRThhuHEbZ9P0vTawIR+i6oPeUMfm SaKqdKrXVGI9ochSffMOTZa2Iq1upLvA5EyGtjhJ3PCh5VZ1KKszg0RvODjbRH1H8lv+ a5QlgMQQIy5E1eEDl3oEeFYl1ZWGr8uGz46k5W/LBSpdYjxP7zXJQUHqhDpw0K+ep8ko DcmQ== X-Received: by 10.28.7.8 with SMTP id 8mr13807195wmh.45.1448219833050; Sun, 22 Nov 2015 11:17:13 -0800 (PST) In-Reply-To: <56520B83.6070302@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195052 Archived-At: --001a114450c8b4ae26052525f48d Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am So., 22. Nov. 2015 um 19:38 Uhr: > I'm not going to belabor the point. If you want to use sizes as version > numbers > it's not worth fighting over. If we ever change a function API without > changing > the structure layout, I guess we'll have to insert a dummy structure > member to > make the size grow. Sounds like a kludge, but there are worse kludges in > Emacs. > Adding back Daniel. Not sure whether he follows this discussion, but he should definitely participate. > > Getting back to the original issue, your worry was that a ptrdiff_t size > would > lead to unnecessary warnings. I didn't get any such warning when > compiling this > with gcc -Wall: > > #include > ptrdiff_t size; > > int main (void) { return size < sizeof size; } > > I expect the warnings you're worried about occur when comparing an unknown > ptrdiff_t with an unknown size_t; they should not occur when comparing an > unknown ptrdiff_t with a size_t constant. I get a warning with both Clang and GCC when compiling with -Wextra. > If that's the case, let's leave it > ptrdiff_t. And even if it's not the case, I'm inclined to leave it > ptrdiff_t, > as any module code will run into similar issues with the other ptrdiff_t > components, so why make an exception for this one? > What other ptrdiff_t components are there? The only other occurrences I see are the argument counts (which are never compared to sizes), and the string lengths (where callers might run into trouble if a buffer is larger than PTRDIFF_MAX, but that seems unlikely). --001a114450c8b4ae26052525f48d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am So., 22. Nov. 2015 um 19:38=C2=A0Uhr:
I'm not going to belabor the point. If you want to use si= zes as version numbers
it's not worth fighting over. If we ever change a function API without = changing
the structure layout, I guess we'll have to insert a dummy structure me= mber to
make the size grow. Sounds like a kludge, but there are worse kludges in Em= acs.


Adding back Daniel.= Not sure whether he follows this discussion, but he should definitely part= icipate.
=C2=A0

Getting back to the original issue, your worry was that a ptrdiff_t size wo= uld
lead to unnecessary warnings.=C2=A0 I didn't get any such warning when = compiling this
with gcc -Wall:

#include <stddef.h>
ptrdiff_t size;

int main (void) { return size < sizeof size; }

I expect the warnings you're worried about occur when comparing an unkn= own
ptrdiff_t with an unknown size_t; they should not occur when comparing an unknown ptrdiff_t with a size_t constant.

I= get a warning with both Clang and GCC when compiling with -Wextra.
=C2=A0
=C2=A0 If that's the case= , let's leave it
ptrdiff_t.=C2=A0 And even if it's not the case, I'm inclined to lea= ve it ptrdiff_t,
as any module code will run into similar issues with the other ptrdiff_t components, so why make an exception for this one?
What other ptrdiff_t components are there? The only other occur= rences I see are the argument counts (which are never compared to sizes), a= nd the string lengths (where callers might run into trouble if a buffer is = larger than PTRDIFF_MAX, but that seems unlikely).
--001a114450c8b4ae26052525f48d--