Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp951437pxv; Thu, 15 Jul 2021 20:57:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRv0D4/DTZjzBjFzfQedL8NpbZIc5erS16o02W7ywbNxyKXmOBqp6a545uOyuAopxlNA/6 X-Received: by 2002:a17:907:7848:: with SMTP id lb8mr9594867ejc.494.1626407868376; Thu, 15 Jul 2021 20:57:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626407868; cv=none; d=google.com; s=arc-20160816; b=xo9NhN0xi62Kuvy3S6VpHKy+ywL1suGXocW0bul8KiU3XmkarOLrGrNYTt+/VspCXl 4A9Hchb/cbReHDwrDxkTkvb+iSVdURsDVt3T5yKnKf1AkIp47Th/WnYrnw78+FW4qg1u OVLUJNr/ngzxD31nUAy7AYFRFOiTTf70Yn8pSiB3PAm4XIBtxdnPud+xIQv/qAtOKUut 2Cto7nhsghUSfRTlPHKIAB0cLBTdYHfiEkJxcyy2AibF8Xjd1wqIy6eqTfJ1m2TNqvRk EHzug5/eAdbgnzNfFLbSdH6arPD21G8qcsqq1hGT2wjidPrZEodHfmEXXS2fg31U2BN8 NCEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=n2Wr+5uyA7JjMZoJmFGDe3oYZzfqWm3fj7GcbRNTWho=; b=jiQo6Vp5v+AOv9DL7SM7/3l+XZboEesZaVsN3yacWj477vymekYxkd1Ef/D992v0d4 kG9tlvgtb8FVI/d2G+Ye5P0Llku/pjCi4bK6nwWroa4oFUuyjJWkElg+ro7VJ5tWBREx FOd7TwY4LrsYUD85aAHiV4VEp6tVZuSC51W5bD6GxoSCUzse/nwk+sFRuWwAps1PZ9h7 gVIN8nTwMrAYmTyvKayNPaXn+Xnv4Fy3zLWRSBfS68MMNbMLXYu35j4HKBmCyYSsGock cGT/yXZAH+iSoejmUrwxxlnSv0Mss3Ykp8ThMBQ7WdUm+egVHLwQTyWnzv7j3TyOLVcB D4Ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb8si11090994edb.495.2021.07.15.20.57.24; Thu, 15 Jul 2021 20:57:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231481AbhGPD6N (ORCPT + 99 others); Thu, 15 Jul 2021 23:58:13 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:39530 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S231139AbhGPD6N (ORCPT ); Thu, 15 Jul 2021 23:58:13 -0400 Received: from callcc.thunk.org (96-65-121-81-static.hfc.comcastbusiness.net [96.65.121.81]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16G3t82r027878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 23:55:09 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id EBC474202F5; Thu, 15 Jul 2021 23:55:07 -0400 (EDT) Date: Thu, 15 Jul 2021 23:55:07 -0400 From: "Theodore Y. Ts'o" To: wuguanghao Cc: linux-ext4@vger.kernel.org, artem.blagodarenko@gmail.com, liuzhiqiang26@huawei.com, linfeilong@huawei.com Subject: Re: [PATCH v2 10/12] hashmap: change return value type of ext2fs_hashmap_add() Message-ID: References: <20210630082724.50838-2-wuguanghao3@huawei.com> <20210630082724.50838-11-wuguanghao3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210630082724.50838-11-wuguanghao3@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Jun 30, 2021 at 04:27:22PM +0800, wuguanghao wrote: > From: Zhiqiang Liu > > In ext2fs_hashmap_add(), new entry is allocated by calling > malloc(). If malloc() return NULL, it will cause a > segmentation fault problem. > > Here, we change return value type of ext2fs_hashmap_add() > from void to int. If allocating new entry fails, we will > return 1, and the callers should also verify the return > value of ext2fs_hashmap_add(). Changing the function signature of functions in libext2fs, which can be a shared library, is problematic, since it can potentially break callers who are depending on the existing shared library ABI. In this case, making a function returning void return something else isn't quite so bad, but it still puts callers in a quandry, since they won't necessarily know if they have linked against an older library which is not returning an error (or not). Unfortunately, there's no other way to fix this, and creating a new ext2fs_hashmap_add2() just to add a return code seems like overkill. Grumble. I guess it's OK to do it, since there _probably_ aren't users of ext2fs_hashmap_add outside of e2fsprogs. But if we are going to make this change, we should really have ext2fs_hashmap_add return a errcode_t, like the other libext2fs functions. - Ted