From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_REPLYTO_END_DIGIT, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2917A1F910 for ; Thu, 17 Nov 2022 07:03:12 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="u6nOO+hp"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 33841396D82C for ; Thu, 17 Nov 2022 07:03:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 33841396D82C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668668590; bh=O0lA19Iim4iXoYcn8+mhlHulBlf6Nrit2Pl51FFKgv8=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=u6nOO+hpb0Ogz6A4iYtnv+0JclDTo0Y8UwvvaCYsedjHYN7GumzxaWUdcZYmeXGXE 4f/g6GF6y0+1VRFGwTGP5r3owacAq93lxpDbUGkz3D4muClzPs0ihAPuwfrznDhh4c VznuXDFbf+VSS2GggLZllYy6FVLOQ4fgcnspzObY= Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id CBE9A38A816D for ; Thu, 17 Nov 2022 07:02:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CBE9A38A816D Received: by mail-ej1-x636.google.com with SMTP id n20so2961242ejh.0 for ; Wed, 16 Nov 2022 23:02:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=O0lA19Iim4iXoYcn8+mhlHulBlf6Nrit2Pl51FFKgv8=; b=oRwdw/KCupKGiqnRKFFKlU7jgg45+kj3bqax/5uzrHvOue/yUCXKq9iAWfChcwZUeB Ptu12k/Uc+sXz7u5gGZtsKiso1Q/Xt1sT0F7xUCVMmnsS/BljOTXBrV2BuC3cdd3BUnp 9AOsCabWcfJ8IQJEj/3qbfMW8A/KBw5Av6+X0BtRRdUBxxxqrG3HPsrufvvm2Ot9Nyeb oexiP+7j1fyzqcCI8i33Y45VDOCPSWCt6IOS5iC1wrU0l8S1knwlADWDvj9eF2ADS6Vi VLCxXs1dET4qREGLH5Md1xuR2YWBGElJc4mQuAgQNhDagM38nmIuRks03MI5kbUY3cAy 1ouA== X-Gm-Message-State: ANoB5pmEmaoHjMwKlTdi7RkPA4tkUl0os+5G2vgB9W2NbeI4BQYt9AJj 6TS97/Hwpg81aRGjssGVJfNZYKlBBh7H1kgASL0hfzcGo7o= X-Google-Smtp-Source: AA0mqf4MDHxkkt0+8pUNzAnKR3RrX5e/Kk64YHIQUDqBqsnCghfLnQEJsTTxBle6PXq5zkz3+izDbs4RtRlImfOza+w= X-Received: by 2002:a17:906:15ca:b0:7a5:7c1c:cc5c with SMTP id l10-20020a17090615ca00b007a57c1ccc5cmr1026372ejd.644.1668668568329; Wed, 16 Nov 2022 23:02:48 -0800 (PST) MIME-Version: 1.0 Date: Thu, 17 Nov 2022 12:32:39 +0530 Message-ID: Subject: size_t vs long. To: libc-alpha@sourceware.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: A via Libc-alpha Reply-To: A Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hi, I prefer long over size_t. This is because, in case the user passes a negative number by mistake then I will be able to check it if the type is long and return immediately. But if size_t is used, then most probably, it will result in a crash - like malloc(-1) will crash the program because unsigned -1 is 0xFFFFFFFF and this much memory is not available on today's computers and probably may not be available at all in future also (RAM size of 2^64 bits is really really huge). Another thing is that if size_t is used an array index then array[-1] will result in wrong behavior or program crash. But with long, the developer can check whether the index is negative, thus avoiding program crash. So, in my opinion, long should be used instead of size_t. I know that original glibc authors had chosen size_t, so there must be some reason for that, however that reason is not clear to me. Amit