From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from alyss.skarnet.org (alyss.skarnet.org [95.142.172.232]) by inbox.vuxu.org (Postfix) with SMTP id 838B32E108 for ; Wed, 4 Sep 2024 13:36:02 +0200 (CEST) Received: (qmail 1307 invoked by uid 89); 4 Sep 2024 11:36:27 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 1300 invoked from network); 4 Sep 2024 11:36:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725449760; x=1726054560; darn=list.skarnet.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=qjuO6PZcHaj7jCd5J/wXJ89iK24kEm9+lPYjt7i40zU=; b=hq+XQ56gF034YJcQlElpW0KZypzma1IfWwIa/8LD+6jNe8V7sby3SOksRVavdx9ooH qGiLuvGta/YSQq+Mjkj+dTXL2TspJ2rjjO1NIGHQBqDJBMEx6I8tOOYMjmvC1oqKTRAS UD1/GdDQWVBNR+UWnyCxwgebSn29m60AVkvN9aeXBNPC6ZbzIdetJ30jK4+oNPQVVo+w Xy5dfLTPqhzwQFcnMO1kfRy7/8sSbAhrL+J3KJ7c3DsagkxYwttPhFnJ0y94dHOuYqG9 rmB+QDBzys9lfLNYYf9xmxfzmn8CR4kz1ySYo3QyfHQipAo7FzmgqFSDLvgBDIyfiQfi SwVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725449760; x=1726054560; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qjuO6PZcHaj7jCd5J/wXJ89iK24kEm9+lPYjt7i40zU=; b=FiMuzNDyr/5hOhel6k5GHfE4uGsP5Xxcgluv+hRblr1ppx6En8WWEPcCew6yNCmQ6A rwVLKAKZV+nxSo8nvaTuBNUCcF0MOJBIzpeMNUkF9O+KVBGvT8aXmNYSmWSRHiyuoO0s LkbIbqtdDpopCxS3grtvNmYgYL9V4BpxbaaLuHe0akuU9XZD0VlE7KHxkzmQjGXBnagk zmZoqKX9a/xZmrR1EvwlUvLkH83Ye0Ami2s5ZRMQfbWulciYrpdJQEGJgrdb+fiakwzh QDtKhFNQy6FYKY4cP4j609OE2K7ppewpN8/oVQj3XNFxy6yAcbpVa0hW+HwLCdfjInwZ lopw== X-Gm-Message-State: AOJu0Yy3Z9idrmX77Fz2s0MhTtNBJDGTTtzcU8O4JzQhtLJfwunBkyyN B1MrMI+qvB6YfoK9Mgz5j44aqRtZNPT4aZa9T+aOB9NZqYFHYvj4P7UHmz8j0Te+zcnWATsWEr3 QDoWHYIk2/XdlhCEeljhJNw14NikZ7Z3n X-Google-Smtp-Source: AGHT+IFS3HpdlJxHAw72Ph3E9KgD/WUjIcDkI/L19v/urm3nPsd1K0zb8Gh/dySjvPLKVY3PO+sKRrrJPI5RRDY1IUs= X-Received: by 2002:a05:6402:2750:b0:5c2:4cbe:abfc with SMTP id 4fb4d7f45d1cf-5c24cbeb2f2mr8635572a12.2.1725449759571; Wed, 04 Sep 2024 04:35:59 -0700 (PDT) MIME-Version: 1.0 From: Zhixu Liu Date: Wed, 4 Sep 2024 19:35:23 +0800 Message-ID: Subject: runit: tryshsgr.c: why not test whether gid_t is short by using "sizeof(short) == sizeof(gid_t)" To: supervision@list.skarnet.org Content-Type: text/plain; charset="UTF-8" Hi, I'm trying to keep runit remaining available in gentoo's official portage tree, see https://bugs.gentoo.org/938282 . I setup a github repo at https://github.com/clan/runit/ for this purpose, following is what I'm doing now: 1. fix all the compilation error(s) 2. eliminate the compilation warning(s) as much as possible Now I 'm in stage 2, when fixing the warning of -Wincompatible-pointer-types, see https://github.com/clan/runit/blob/master/admin/runit-2.1.2/src/tryshsgr.c As G. Pape has commented at https://github.com/clan/runit/commit/5a7b8099ae638ce72abae2c4d8cac7ce33477522 > "tryshsgr" is specifically there to check whether the size of gid_t is short, > it doesn't matter if it fails at compile time or run time. But with this > change, it always succeeds, and so always size short is > assumed, even though most systems should have unsigned int I guess. At first, what Pape said is correct, I didn't fully understand the semantic meaning of this check before fixing. I should use debian's patch (0029-fix-ftbfs-with-gcc14.patch) which casts x by (gid_t *) instead of changing from short x[4] to gid_t x[4] in my current patch (which is wrong). But I'm just wondering why we don't use "sizeof(short) == sizeof(gid_t)" to do the test which is more intuitive? Part of the reason is that I found the test of the result depends on the running user's supplement group config after I changed short to gid_t, which is very confusing. If I run as root with many supplement groups, the test fails, if running as another user w/o supplement groups, the test succeeds. Of course, after the change from short to gid_t, the test logic or assumption is wrong from the beginning. Thanks.