From owner-svn-src-all@freebsd.org Sat May 21 22:08:46 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBD89B44E6E; Sat, 21 May 2016 22:08:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A14641210; Sat, 21 May 2016 22:08:46 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f171.google.com with SMTP id 190so172154616iow.1; Sat, 21 May 2016 15:08:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=bxJTQI3uJKgCL8oJL9w0yRiqHn0Sfc0pIJV/gqPuHn4=; b=mkUYhTDoluMOnIAect81owEZwbNbginppcEY1uvyJDxhcEjF64wAQtLCWQZGFSQzYi xAirU79bhSJCztTtrks0NTu7O+ly0RewH+na466Lkq+aWFvlpgqF+FjFm5L5Ohc01OqR TWLFOYv3hXhpwJ3lqwrRCh197xxTDmUa1bvN97fLCcaAN7R6QYoe3ocD2PP+jznozbm5 +OC6571allPzxCkt08oy9eJ4B0H6O7Zt+3r81VOnUtzX/tpHxxQsxyrgtMbwpxBOJew2 0tYDAe5RDyu6UrIQKWZ938KotpI7gvsQZM6dEoSPfEYWcQr8vVhJLtAM7ccqohY4faQb iTIg== X-Gm-Message-State: ALyK8tLwq2F8jV8SLUWXqXUaiKqvMUui0Qv5CwQOGq9SywY2s3OwcHFOf9g3515FM1pGVQ== X-Received: by 10.107.134.143 with SMTP id q15mr2488670ioi.25.1463868045214; Sat, 21 May 2016 15:00:45 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com. [209.85.214.49]) by smtp.gmail.com with ESMTPSA id j70sm4045279ioi.19.2016.05.21.15.00.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 May 2016 15:00:45 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id z123so10010616itg.0; Sat, 21 May 2016 15:00:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.36.131.67 with SMTP id d64mr6704506ite.34.1463868044548; Sat, 21 May 2016 15:00:44 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.36.205.70 with HTTP; Sat, 21 May 2016 15:00:44 -0700 (PDT) In-Reply-To: <20160521123908.V1914@besplex.bde.org> References: <201605201950.u4KJoWA5028092@repo.freebsd.org> <20160521081930.I1098@besplex.bde.org> <20160521103528.I1539@besplex.bde.org> <20160521123908.V1914@besplex.bde.org> Date: Sat, 21 May 2016 15:00:44 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r300332 - in head/sys: amd64/amd64 i386/i386 From: Conrad Meyer To: Bruce Evans Cc: Konstantin Belousov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 22:08:47 -0000 On Fri, May 20, 2016 at 9:13 PM, Bruce Evans wrote: > On Fri, 20 May 2016, Conrad Meyer wrote: > >> On Fri, May 20, 2016 at 6:10 PM, Bruce Evans wrote: >>> >>> >>> Signed integers are easier to understand provided calculations with them >>> don't overflow. >> >> >> How? > > > For the same reasons as in applying mathematics. Applying mathematics > was harder before negative numbers were invented. Negative numbers > are actually not easy to understand at the technical level (the usual > representation of them is equivalence classes of pairs of non-negative > numbers), but their properties are easy to understand and work with > once you are familiar with them and don't think about their > implementation details too much. > > Ordinary (real) numbers (including negative ones) also have good ordering > properties for all operations. > > Computer arithmetic can't represent all ordinary numbers, but gets closest > by representing ordinary integers as C signed integers perfectly when no > overflow occurs. > > By using C unsigned integers unnecessarily, you throw out invention of > negative numbers and might have to work with the unfamiliar and badly > behaved ordering on them. C programmers have some experience with this > ordering, but apparently not enough to usually avoid bugs. > >> The rest of the argument seems to be, using u_int is bad because more >> unsigned is always bad. But I haven't seen a good reason to believe >> that is so. > > > Not always bad. Sometimes you must use C unsigned integers to get a full > representation without wasting many bits, or actually want the ordering > of unsigned integers. The main case is representing other C things like > pointers. Differences of pointers are still hard to handle. > > Bruce Thanks for explaining. Can you explain a little bit about the badly behaved ordering of unsigned integers? I am not familiar with that. Best, Conrad