From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4067 invoked from network); 10 Apr 2022 21:02:19 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Apr 2022 21:02:19 -0000 Received: (qmail 5979 invoked by uid 550); 10 Apr 2022 21:02:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27852 invoked from network); 10 Apr 2022 16:39:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.ustc.edu.cn; s=dkim; h=Received:Message-ID:Date: MIME-Version:User-Agent:Subject:Content-Language:To:References: From:Cc:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=f eINSldzaLtbSHplW7u7RwnzfueElJCc5YjbjqCBimY=; b=vB/ki8DVOBmruSMXD g4JHJ3OD8i0V8W7YewHUQOnjl6XBurdp427UeX7bYcoNoxIYLqXKIMPoObTHoiM/ e1gfRcm2f09WDGvObyOb8F4/owj2v5K3g3+GHcH+M3mJwOrmJPiQhpkznT1i4Din JLdHrlWM1IfD/Yxabx/5KEBVLY= Message-ID: Date: Mon, 11 Apr 2022 00:39:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: musl@lists.openwall.com References: <1649605497.38rdgg2ifl.none@localhost> From: Keyu Tao Cc: alex_y_xu@yahoo.ca In-Reply-To: <1649605497.38rdgg2ifl.none@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:LkAmygC38txHCFNigq8fAA--.21625S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WFyfGryUtrW8CF1fKrykZrb_yoW8Aw17pF W7KanYyFn5KryY9an5Zr1kXF4SvFWfAFW5Wr45Z34kC3Z5tr92ga97Kr45Zwn2vrWrWF9r Zr4ftw4UJa4DXa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvIb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I 8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r 4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487 MxkIecxEwVAFwVWUMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I 0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWU XVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcV CY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf 9x07jTMKZUUUUU= X-CM-SenderInfo: 5wdry5o6pdxzwoxv3uoohg3hdfq/ Subject: Re: [musl] getmntent() fails to parse when source is empty string Thank you for your reply. I once believed that glibc can handle the leading whitespace as `mount` in my host is working correctly. I rechecked just now and found that the `mount` in Alpine container is provided by busybox, which uses `getmntent_r()` to parse /proc/mounts (in mount_main()). However, the `mount` in my host is provided by util-linux package rather than busybox, and it does not use `getmntent()`. I used `ltrace` to see all library function calls, and the busybox mount implementation in glibc also provides incorrect result like this: getmntent_r(0x555adeefa2c0, { "/tmp/test1", "tmpfs", "rw,nosuid,nodev,relatime,inode64"..., "0", 0, 0 }, " /tmp/test1", 1016) = { "/tmp/test1", "tmpfs", "rw,nosuid,nodev,relatime,inode64"..., "0", 0, 0 } getmntent_r(0x555adeefa2c0, { "none", "/tmp/test2", "tmpfs", "rw,nosuid,nodev,relatime,inode64"..., 0, 0 }, "none", 1016) = { "none", "/tmp/test2", "tmpfs", "rw,nosuid,nodev,relatime,inode64"..., 0, 0 } It looks like not a bug of musl now :-). 在 2022/4/11 00:00, Alex Xu (Hello71) 写道: > It's worth noting that octal escape sequences are also not supported. > This has been reported previously, e.g. at: > > https://inbox.vuxu.org/musl/HE1P192MB0010D60AAC4BA0F08F1A5644FB5E0@HE1P192MB0010.EURP192.PROD.OUTLOOK.COM/ > > https://inbox.vuxu.org/musl/87o85j8sru.fsf@atufi.org/ > > I think the empty source is basically impossible to support with > getmntent though. Both the glibc and musl implementations ignore leading > whitespace, probably because getmntent is more commonly used with fstab, > where users may have unintentional leading whitespace. If empty sources > are an issue for your program, I would suggest using your own getmntent > implementation.