From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id E13603857C50 for ; Fri, 9 Jul 2021 20:19:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E13603857C50 Received: by mail-wm1-x335.google.com with SMTP id a5-20020a7bc1c50000b02901e3bbe0939bso7049499wmj.0 for ; Fri, 09 Jul 2021 13:19:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=go0RwTrtC8ADJLSfhebVyCzjm5Gt+9MgT2A5wfoEBXY=; b=Fgfmp15D685xI8oPSykxigR7ymEvEl9VS/rVeoD93WJH9WyzQtsE9wxDvS3pmPsnjD 24HzKhYJZ17noxJP/p+ZHypfkhTKGrk+1JEDOsb8fJWLEgv4yt37mk9Qsttg44BWJJaA tpwSOeOzbk+1G87ufAYVMlDEcYQLb/0KNjfCHruUaT3WBt4mOEBRCF5nkaXrfS09Pmji r9dNZJh8nYANsWljSq1oGcJLjD95Rc3gtJ3p5iVhuzsng5q3DrPV/sAur5bsH12qC5pD 24lhYPhYSyIPQLJVbGKsG0d5vxa+c/vrTZ1idEF8nhftaa8NbyEdUH8AESzNQlIqU1/l 3gfg== X-Gm-Message-State: AOAM533seXwvK5HRP2ZZ2csCt6dxAydciJYojIfX9Xe7NXXT2rfcgmP7 9+uQBHkURvtVG0cm7T1om0A= X-Google-Smtp-Source: ABdhPJzynsYBmpkmBJ2wki8Um+lvS64mUN/sM0Cjm1Tol35lLfwr4pknSXpc6q5yfyvv1M564Ekg4w== X-Received: by 2002:a05:600c:4f81:: with SMTP id n1mr743487wmq.16.1625861993021; Fri, 09 Jul 2021 13:19:53 -0700 (PDT) Received: from [192.168.1.143] ([170.253.56.53]) by smtp.gmail.com with ESMTPSA id b7sm6011749wri.96.2021.07.09.13.19.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 13:19:52 -0700 (PDT) Sender: Alejandro Colomar Subject: Re: strlen To: Martin Sebor , LIU Hao , johnsfine@verizon.net, "gcc-help@gcc.gnu.org" , "jg@jguk.org" Cc: "linux-man@vger.kernel.org" , "fw@deneb.enyo.de" , "mtk.manpages@gmail.com" References: <0bf239e9-cfc7-8889-ca00-b1d1566bd174@jguk.org> <87lfhpgxf8.fsf@mid.deneb.enyo.de> <017a5a66-ba66-7cc8-c607-f851c2e54fc4@jguk.org> <87363whf2z.fsf@mid.deneb.enyo.de> <48e874cb-2b95-2783-ddfc-ae12d9aaf8f5@jguk.org> <87bl7fozxi.fsf@mid.deneb.enyo.de> <23679a28-5986-0af2-4d98-7de68ed0deec@jguk.org> <53b3666b-d200-ef97-b050-cc38669c61cd@gmail.com> <564825ed-1e1f-b344-da35-1b83c551ed5f@jguk.org> <5566b180-1333-d73b-22ee-6c6d32053921@jguk.org> <1627912755.3783669.1625745946723@mail.yahoo.com> <59a70222-a46f-1e65-c9db-6c9e577c8adc@126.com> <8e0db7f8-bbdb-1dc1-b4ce-5f2da0bf1708@gmail.com> From: "Alejandro Colomar (man-pages)" Message-ID: Date: Fri, 9 Jul 2021 22:19:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <8e0db7f8-bbdb-1dc1-b4ce-5f2da0bf1708@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 20:19:55 -0000 On 7/9/21 7:26 PM, Martin Sebor wrote: > On 7/8/21 8:08 PM, LIU Hao via Gcc-help wrote: >> 在 7/8/21 8:05 PM, johnsfine--- via Gcc-help 写道: >>>   This is not the forum for such a discussion.  But I want to make >>> people reading this aware that many expert C and C++ programmers >>> (likely a majority) consider that advice to avoid unsigned types to >>> be horrible advice. I'm sorry if it's not the right place, I could remove the lists from the CC if it's too noisy, but I think an important point is here, and a couple of emails won't damage too much the mailing lists. On the other hand, I consider bad etiquette removing CCs from a discussion. >>> I advise people to avoid signed types and I do so myself.  If an >>> integer value won't be negative, it shouldn't be signed.  That makes >>> your intent clearer to anyone reading your code, and (especially in >>> x86-64) lets the compiler generate smaller and faster code. As others have showed with facts, and the Google style guide also hints, using unsigned types just removes the opportunity of the compiler to optimize on overflow, because it has to account for wrapping around. >> >> That makes no sense. Would you prefer unsigned integers to signed >> ones, for something that can only be one of {1,2,3,4}? Just because >> something can't be negative, does not mean it should be unsigned. That. The same way that because a number is never going to be greater than 100 is it any better to use [u]int256_t. Just use int, unless you have a reason not to. Please John, read the paper from Bjarne about unsigned types, it really covers a lot. If you still disagree after reading that, feel free to argument it. > > There are benefits to making that explicit by choosing an unsigned > type: the result of converting a narrower unsigned type to a wider > unsigned type is unchanged.  The result of converting it to a wider > signed type may change.  This has an impact on value range propagation > which in turn can influence other optimizations as well as warnings. That problem with implicit conversions to larger types is not a problem of signed integers, not even a problem of unsigned integers. It's a problem of mixing both. If you use signed integers for everything, you won't have that problem. Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/