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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 040661F45E for ; Sat, 15 Feb 2020 13:17:05 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=Dxqempju3nx/CaI5XLBm6YF01OtEBDUwdTMy6asX+/4 +MIIG+HuKoqPjbSww/fFRCe0WZYd7+RvTOLz+lizXThaPpvF6K9tEzLx5Zt0VWFn DcTuFr6tlcUITgM1V69HP1DSQtAsTeeUvsUJ7VzTtcYZoxBLwwOE3+dznYG5gtSc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=DCLi4g2hmXCeqiKfHAQthvNo8sY=; b=KgGdky7pmHuNfqMEz 3P+0YM+b8lTVPM9evw6wOW34qXfADC4Kw3Jl0bmATFPg84Db3jiiQwcSmW1GF0Zw gSWQvbvzzA4bSTyQPNO9yFWPTwJm9jNQLUkC13lBQPA92opj6iRJxvqgTIkD87OK 2aTa9fOMbu9LgxxUjQBnr24W6I= Received: (qmail 76799 invoked by alias); 15 Feb 2020 13:17:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 76789 invoked by uid 89); 15 Feb 2020 13:17:02 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581772620; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WQHKCPFMsebYJjYhbFBrx3hmI45T0z7R7Aps5WuLk1E=; b=MEIsVyM/oAYC13gL9i54gCciaj2YnyF25sZqZPJr9/BiJYfKQsrmHBqFPaExGVdeiI7oPA zemuAOruWZo6r7QkChGPlxZ1C1CtWIRAcln2jxF0RMTmIcF4aVv1NIjeCkPabkwhvN5eEH 8wZzNmhTHELH+Prl7Zkle6tgz22Jj+U= From: Florian Weimer To: Paul Eggert Cc: libc-alpha@sourceware.org, Samuel Thibault Subject: Re: [PATCH 1/3] : Add type safety and port to Hurd References: <61b49643-9c7b-7060-6eb7-21060dd6e22f@cs.ucla.edu> Date: Sat, 15 Feb 2020 14:16:52 +0100 In-Reply-To: <61b49643-9c7b-7060-6eb7-21060dd6e22f@cs.ucla.edu> (Paul Eggert's message of "Fri, 14 Feb 2020 12:28:52 -0800") Message-ID: <87wo8oxa63.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable * Paul Eggert: > On 2/14/20 10:11 AM, Florian Weimer wrote: >> + /* A positive int value has at most 10 decimal digits. */ >> + char buffer[sizeof (FD_TO_FILENAME_PREFIX) + 10]; > > This should use 'INT_STRLEN_BOUND (int)' rather than '10', where > INT_STRLEN_BOUND is taken from intprops.h. Then you don't need the > comment (and the code won't break on future ILP64 platforms :-). But INT_STRLEN_BOUND is 11, right? >> +char * >> +__fd_to_filename (int descriptor, struct fd_to_filename *storage) >> +{ >> + char *p =3D mempcpy (storage->buffer, FD_TO_FILENAME_PREFIX, >> + strlen (FD_TO_FILENAME_PREFIX)); >> + if (__glibc_likely (descriptor >=3D 0)) >> + { >> + if (descriptor < 1000) >> + p =3D digit123 (p, descriptor); >> + else if (descriptor < 1000 * 1000) ... > > It's not clear what that "descriptor >=3D 0" test is doing. I assume > that a precondition is that DESCRIPTOR is nonnegative; if so, this > should be mentioned and the test removed. If it's not a precondition, > the code should do the right thing if DESCRIPTOR is negative (I > suppose, return a filename that cannot be opened, though it doesn't do > that currently) -- which should also be documented but I think this'd > be overkill. The problem is when an application passes an invalid descriptor to some libc function and that ends up with __fd_to_filename. We should not make matters worse in that case. Maybe we should use an assert? Thanks, Florian