From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf42.google.com (mail-qv1-xf42.google.com [IPv6:2607:f8b0:4864:20::f42]) by sourceware.org (Postfix) with ESMTPS id 3FB513835087 for ; Wed, 9 Dec 2020 00:18:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3FB513835087 Received: by mail-qv1-xf42.google.com with SMTP id u16so140015qvl.7 for ; Tue, 08 Dec 2020 16:18:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XsXSMLCb/QxW7hajt1igw4wKHMZE7isItuCj/wjFYr4=; b=mSjGkX4WGKwhWR/yYsPfD4ubt5CzgTTw40qF/SzKdjU7z4hesYiujZFVG5ypn7oqxN GZSAuYQ7i/YxOFHFsXcJM4sRp9Thz8cDIDsgx9DsbzykwIJS8Rzj2zm8ZxZD0kHZ43cp Nk+Wqe2tVPfG7KUFsojcHqIoiYPcnI7LnPkYhuM08RNIh/P4flDS4nRtsagWxWFQL5oK OcnDZeA6vj8KDu1ic/LqTCvANtmHXYm2+hVCtoEcAP6l/zPqISt5lFVbz54lTJa4BWVK XOVX6W7kxxwtTyoRE35G8CSXntYSCNOPtrjRk6sUv3Awuq7L18NHwm9IypW3Sc9fHIu6 /DgA== X-Gm-Message-State: AOAM532N1GHJbkNBg7DUXt+zy1KmMZLVrk8D4PXce0+vmRuB6uO0rREB FR55tBZOtiXd22QWSovXX/KiNL1KAOk= X-Google-Smtp-Source: ABdhPJwWHSIvJg+c6g/xsbgs1A7Tsdd6CeLrNRnEr7cLdOU/KuQnB9xvtI4GNEzOt5gJLePujIvhjg== X-Received: by 2002:ad4:5106:: with SMTP id g6mr949168qvp.1.1607473115624; Tue, 08 Dec 2020 16:18:35 -0800 (PST) Received: from [192.168.0.41] (174-16-97-231.hlrn.qwest.net. [174.16.97.231]) by smtp.gmail.com with ESMTPSA id i11sm302362qkg.45.2020.12.08.16.18.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Dec 2020 16:18:34 -0800 (PST) Subject: Re: [PATCH] more out of bounds checking improvements To: Florian Weimer , Martin Sebor via Libc-alpha References: <176ba75f-4299-073f-8319-66dbf9fe3f42@gmail.com> <87mu09ata4.fsf@oldenburg2.str.redhat.com> From: Martin Sebor Message-ID: Date: Tue, 8 Dec 2020 17:18:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <87mu09ata4.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 00:18:37 -0000 On 10/26/20 9:41 AM, Florian Weimer wrote: > * Martin Sebor via Libc-alpha: > >> Besides attribute access, the change adds attribute nonnull to >> the readv and writev functions in misc/sys/uio.h. The functions >> don't necessarily access the array elements when their count is >> zero but neither POSIX nor the Linux manual document this so it >> seems appropriate to warn. > > This change is questionable because it breaks interoperability with > abstract data types such as std::vector, where the base pointer can be > null when the array is empty. The kernel does not return EFAULT in this > case, as expected. Let me separate this out from the main patch if it isn't straightforward. Although POSIX doesn't require the functions to fail, it does suggest, albeit obliquely, they may fail when the iov pointer is null: The iovcnt argument is valid if greater than 0 and less than or equal to {IOV_MAX}, as defined in . The writev() function may fail and set errno to: [EINVAL] The iovcnt argument was less than or equal to 0, or greater than {IOV_MAX}. Passing the functions a null iov pointer is only realistic when iovcnt is zero. The former is nonconforming and undefined under any conditions (null isn't a valid argument to any library function unless specified otherwise), and the latter may cause the function to fail. A warning for it seems to me both appropriate and helpful, certainly in the absence of the Glibc or Linux man pages documenting the behavior under these conditions. Martin > I think we need a special case for this. > > Thanks, > Florian >