From nobody Fri Mar 11 15:40:15 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 159C71A0E3F9; Fri, 11 Mar 2022 15:40:24 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KFVWC63NBz4QyP; Fri, 11 Mar 2022 15:40:23 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-ej1-f52.google.com with SMTP id bg10so19945237ejb.4; Fri, 11 Mar 2022 07:40:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to; bh=8TykCfAy8zecjVbdTP0QHqizSOonxMzT/W7y7BpSJ4k=; b=b1QhOFcJKVCm+Nlm8LqG8ufdh4CGmhpb8lmbpPGm4XXAsvbiSe/p+6nRm/vGJ4tQAX 7bviIm0L/Bk47IfrBlBXSbfwPKrhuMx9jOAHGfmiwRWBk3kV6F7ENEFrA47p8ELnajgR ky1zBsUDriCaFJ62wA6tXPv4maHQUFOd36l2z0GAlouPhwUyTZOTReEbNMuPPRgLvSbd jBpPpdpVjvcUZWKHpyZY4UxB9LhNsREhW9tDX4gCjVf4gqg0enkCFeZ16J08+D6qKqMc fPBhWafZeWIGwHB6pz1KXIpKlGTiH8FoBr4DcgKQhAvzBH/6ikjjaor3iGRJlLh8qIUY kh/g== X-Gm-Message-State: AOAM531DWtyKEWJqsuE9hb3BbMEXkBWBfqqQYzLWBcIpZKpgQ/eCL3M+ keHFlc978VdJ91PLHcElhoM1See/Bw5Q8A== X-Google-Smtp-Source: ABdhPJwVDsSjBqL8k8wKjNnkZfdJdNW5hp7U+U8jT6AkTAFR8p+36I62aCBDiRfbDnwXtBQQtPiVkA== X-Received: by 2002:a17:906:9744:b0:6da:9e49:9fe3 with SMTP id o4-20020a170906974400b006da9e499fe3mr9146340ejy.319.1647013217411; Fri, 11 Mar 2022 07:40:17 -0800 (PST) Received: from ?IPV6:2a02:8109:9880:1d70:5e5f:67ff:fef4:ffd8? ([2a02:8109:9880:1d70:5e5f:67ff:fef4:ffd8]) by smtp.gmail.com with ESMTPSA id o21-20020a170906289500b006d144662b24sm3035054ejd.152.2022.03.11.07.40.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Mar 2022 07:40:16 -0800 (PST) Content-Type: multipart/alternative; boundary="------------Lowk4kw4691zA9zNqjgW2F3W" Message-ID: <5c05a9a5-2160-48e7-6e0f-2e7784b7e3aa@FreeBSD.org> Date: Fri, 11 Mar 2022 16:40:15 +0100 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: Warner Losh , Hans Petter Selasky Cc: src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202203110942.22B9guNt032463@gitrepo.freebsd.org> <4eaba9f4-7cd6-5af3-d745-97932501a2fc@FreeBSD.org> From: Mateusz Piotrowski <0mp@FreeBSD.org> Subject: Re: git: 419822b372f5 - main - libgeom(3): Use calloc instead of malloc and bzero. In-Reply-To: X-Rspamd-Queue-Id: 4KFVWC63NBz4QyP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------Lowk4kw4691zA9zNqjgW2F3W Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/03/2022 15:15, Warner Losh wrote: > > > On Fri, Mar 11, 2022, 4:10 AM Hans Petter Selasky wrote: > > On 3/11/22 11:57, Mateusz Piotrowski wrote: > > Hi, > > > > I grepped out tree and there are many other places, which could be > > converted to using calloc. Is there anything to watch out for when > > converting malloc and memset call pairs to calloc? > > > > If you have a tool for it combined with a review, should be pretty > straight forward. > > > You likely can use coccinelle to find these. It works better than grep. Everything is probably better than grep in this case. I actually used weggli to find those malloc/memset uses. I was actually thinking if something about the calloc implementation could bite us if we just change all malloc/memset occurances to calloc. Something similar to what is described in this article for example: https://willnewton.name/2013/06/17/calloc-versus-malloc-and-memset/ Best, Mateusz Piotrowski --------------Lowk4kw4691zA9zNqjgW2F3W Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 11/03/2022 15:15, Warner Losh wrote:


On Fri, Mar 11, 2022, 4:10 AM Hans Petter Selasky <hps@selasky.org> wrote:
On 3/11/22 11:57, Mateusz Piotrowski wrote:
> Hi,
>
> I grepped out tree and there are many other places, which could be
> converted to using calloc. Is there anything to watch out for when
> converting malloc and memset call pairs to calloc?
>

If you have a tool for it combined with a review, should be pretty
straight forward.

You likely can use coccinelle to find these. It works better than grep.

Everything is probably better than grep in this case. I actually used weggli to find those malloc/memset uses.

I was actually thinking if something about the calloc implementation could bite us if we just change all malloc/memset occurances to calloc. Something similar to what is described in this article for example:

https://willnewton.name/2013/06/17/calloc-versus-malloc-and-memset/


Best,

Mateusz Piotrowski

--------------Lowk4kw4691zA9zNqjgW2F3W--