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_MED,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 B305C1F910 for ; Thu, 17 Nov 2022 09:48:46 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="UuJa2n0Y"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E74B5396DC2D for ; Thu, 17 Nov 2022 09:48:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E74B5396DC2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668678525; bh=UesF5cifHwlraW7Ss8seiO2wFzdETU8jt9peOLWDRek=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=UuJa2n0Y8QvCd5EL8qFTKDNb/zAp9mI8YXkTYV6lsUOT40eYVnhOBz3sfk5YvI0JJ IXMm05UaBwbD0R3OaOYy+k60x4mInDoY29/WEa/VGrdYSk3xVyjxp0MD6vOrN/g/26 gFA10H7N2BuTtFgzgcgr2AwebjNeO5MGMv3PMtnY= Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 9BAA539730C1 for ; Thu, 17 Nov 2022 09:48:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BAA539730C1 Received: by mail-ej1-x62b.google.com with SMTP id f27so3764060eje.1 for ; Thu, 17 Nov 2022 01:48:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UesF5cifHwlraW7Ss8seiO2wFzdETU8jt9peOLWDRek=; b=Nn9uwNT+FpO6Hzp5AeSHEfYIlgeRL1BgYQ6QsjsEHi96FIYfxE5slxxRaiOS/Dsq1b ddi0B+xVMhlbEMFvnAA2ykII9A+gWGvLVk1xzkWR0NTsLp2zxcfoGsEe0jNoAB/ReD5n GmfaO93XC26LnYJD6kZ0mMgJ4dYfa736NLYZEKaENwqqmsm+yt15PjWpyp4N2ZTrzLbd SshlII5urnZ43hfiFg3oHjK8zYyXnUtVkSepqlHXtedLweDe6Z+uBmvZm4RJpAg6f+Ye tCaMu3GG4XYipjXe3G0DBpeIvYb1wFm4eDMbpwGZwBCrdMbhurGTRjxI2KeGhCR0FHX1 o4hA== X-Gm-Message-State: ANoB5pkvaGSZL+PM7t02oC+0PPICyvsfnyw5reAL5UzME7VOa6kcxLMH 9WYzbHoIAGQ92DSOha0BZ1y3pPkxQQJlVCEe4hc= X-Google-Smtp-Source: AA0mqf4JrDLIUp9d/T6rO0DinzABmxjlr2CFHjIQmFaW1SWu3fnfy8GcbFAH8b9PL68p6uTPMPbgqhDTYUqyLLs/LBI= X-Received: by 2002:a17:906:8c4:b0:7ae:fbe6:e7ca with SMTP id o4-20020a17090608c400b007aefbe6e7camr1505864eje.408.1668678500233; Thu, 17 Nov 2022 01:48:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 17 Nov 2022 15:18:09 +0530 Message-ID: Subject: Re: size_t vs long. To: Alejandro Colomar Cc: 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" > > > > But if size_t is used, then most probably, it will result in a crash - > > And I love that. Crashing is the best thing you can do. That tells me > immediately that I wrote a bug. Isn't that what we wanted in the first place? No, I don't want a crash if I can get an error value returned back and errno being set properly. > > > 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). > > We're not so lucky with malloc(3), since it's virtual memory, and you won't get > it all at once. But yes, sooner or later, if you passed -1 to malloc(3), you'll > see a crash, which is a Good Thing (tm). > I am programming since last 35 years and I haven't heard this kind of logic before that crash is better than getting an error value returned back and errno being set properly. And I have worked for companies like Cisco Systems and Juniper Networks. Crash is not a good thing otherwise things like checking the validity/sanity of arguments passed in a function would not have existed. If we all loved crashes then we would never check any argument passed to a function. We would simply go ahead without checking the arguments and let the function crash and then let the user debug it. Getting an error value returned back and errno being set properly is way more easier than debugging the crash. Debugging a crash can take several man hours, but by getting an error value back and then checking errno can solve the issue very quickly. > > > > 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. > > And what do you plan to do when you detect -1 in your code? Set errno to > EPROGRAMMERNOTSMARTENOUGH and return -1 from your function? Looks like you are trying to make fun of me. I don't appreciate this. However, you can set errno to something like - "ENEGATIVESUBSCRIPT". Anyways, to shorten the discussion and making it to the point, I would like to know why is size_t used in malloc() when a negative value (passed by user by mistake) can crash the program. Using long and checking for negative values can prevent the program from crashing. Some people might say that user should check for value being negative but for checking for negative values long is required, not size_t. So, then the user will end up using long instead of size_t. So, in effect using size_t in malloc is not correct (unless we get further insight that explains why size_t is correct in malloc()). Just saying that size_t is good and long is bad (in malloc()) without any reasons will not make any sense. Amit