From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id B84253858425 for ; Sun, 3 Dec 2023 15:38:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B84253858425 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B84253858425 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::230 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701617911; cv=none; b=gxbbVO+W6+zqigkMvb3tuXTRZrFGxtWXOnnfPUSL1RRfkjziwuVMjgQgZJxvoS5kHwyTEzgFTPDvle9jANuDEg2tFDcLvyhgLa3dcC5e+wS9wS20W7312l+nTAHpndbzd1ApVnGgr9jAb+EGYq6sg4qAzioR0SHdiyrcdmUiHlo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701617911; c=relaxed/simple; bh=mnzyInFQpWknXqq04+Cg0imZE7m9qTC2UNPMyMJ5gno=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=QoIO3Nlap32nhLWyTN0pNwDCm9pv3cHpZDDzYLo1ZZhYKEZCN/6b7OE/dehfJo2SebVFLeNl4rprzNqN5GZiA7zdX39sdgDWVTg626UA0yOnYFRfmMGhgqKrgyL+N6FPbSgL+CdVDXQMfIob1v5HraqMPTgPwXWijHRHT/dB9XY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2c9f85eff28so9679921fa.3 for ; Sun, 03 Dec 2023 07:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701617907; x=1702222707; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=herr6GyqevHrJ1QgNbr69a2YE11SKruKwxbMP8vZKRU=; b=HXG0zXxFub5jKMjmBMimPEAyKVG1S06fRT+gVnXF9EHQGDGmBGAmG+3USv4Hxyog47 hCISohb1v0tu0fg4rlqJ5yD2ss88/a0Q2WOfnnSf8E1xsK0oTzUyB80L/Gi3PBerAYvk FlLu662dvDi6c5FzGGWdypEePIQsuj2i0NqJbJfmS17VxABG67sGE0jiRgYMoF9P+RKC PxPfDbtknk5gyxm/N5HsofBKRJX4i5zWiamj+lZvecL7vpvAaecUf225hAJ2uy6yLSxN feefUt6xnOX+kLNBMwFh31ixCowRroHH1b1oX5WG54k/R6Nca1Q8T6hz8JuBejEx12DJ XRuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701617907; x=1702222707; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=herr6GyqevHrJ1QgNbr69a2YE11SKruKwxbMP8vZKRU=; b=nLwfLK602SWkMFWjF2EmCspSFuTD8gudZe1dKM3u4kdqIphONzauIGu/nZAfmVdhnN FZhGoHK/BmLD+ooEE1zJ6LScpVYbR1zuEpMR/xgB4SYixWLG8ghWr1e6bbuAu4HJADBy ay2bGLHI7C4v9bLSV1D4MyymdgqhDg+XOhBn4H1jMRoQLCfdyv8huVm+gpjsuSjvsadk CNTznaA+e4B6VPA0qOmkqsYRgGsbNxbtdyrOu7u7O0RZswRU4GHiXrwiZIDPsbM67+OK 4yGwzCasP3e+Ib3BQ65fqWscoBXZKOEB3FouZFqgpbHFqDe49s2X/LMTIPVTWw1u859G xCmA== X-Gm-Message-State: AOJu0Yy8+gL2qXvRXgH8YIQgFMPkF0dGy1k1ux4fHDZGVsmoUvfkJxRr fuZk1dwiUtsNo4fi97S7HsUpXH87aC7IMeVPQ58= X-Google-Smtp-Source: AGHT+IF294v+9v3RA12/McMfvCKogROTd3yjMwHZYVJthB5x/FDPhcvS3UiluClaO7rEFMQOjQeGyFb3sRjx7ybcKMs= X-Received: by 2002:a2e:984c:0:b0:2c9:f0b1:9d8c with SMTP id e12-20020a2e984c000000b002c9f0b19d8cmr961764ljj.38.1701617907321; Sun, 03 Dec 2023 07:38:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amol Surati Date: Sun, 3 Dec 2023 21:08:22 +0530 Message-ID: Subject: Re: restrictness of strtoi(3bsd) and strtol(3) To: Alejandro Colomar Cc: libc-help@sourceware.org, gcc-help@gcc.gnu.org, Guillem Jover , libbsd@lists.freedesktop.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello Alex, On Sun, 3 Dec 2023 at 17:05, Alejandro Colomar wrote: > > Hello Amol, > > On Sun, Dec 03, 2023 at 04:29:07PM +0530, Amol Surati wrote: > > The section "7. Library" at [1] has some information about the 'restrict' > > keyword. > > > > I think the restrict keywords compel the programmer to keep the string > > (or that portion of the string that strtol actually accesses) and the > > pointer to a string in non-overlapping memory regions. Calling > > strtol(p, &p, 0) should be well-defined in such cases. > > That would justify the restrict on char **restrict, but it doesn't > justify the const char *restrict. > I think a more appropriate prototype would be > > long > strtol(const char *nptr, char **restrict endptr, int base); > > The above means that endptr points to memory that is not pointed to by > anything else in this call. Referring to the points you make later, removing the restrict-qualifier from nptr then explicitly permits *endptr and nptr to alias, as the types are now devoid of restrict-qualifiers. > > But any of the following is somewhere between confusing and a lie: > > long > strtol(const char *nptr, > char *restrict *restrict endptr, > int base); > > long > strtol(const char *restrict nptr, > char **restrict endptr, > int base); > > long > strtol(const char *restrict nptr, > char *restrict *restrict endptr, > int base); > > These 3 from above all mean the same thing: nptr, endptr, and *endptr > each point to a different memory region. That's of course a lie, > because nptr and *endptr may alias. The formal definition by ISO C, > which is in terms of accesses, seems to be compatible with these uses of > restrict, because as long as the function doesn't access the memory, it > doesn't matter if they overlap. However, that definition of restrict is > useless IMO, and still doesn't justify why the compiler isn't > complaining at call site, where it can't know that strtol(3) won't > use **endptr. I think I understand. Since strtol is an external function, the compiler, when when compiling strtol(p, &p, 0), has enough information, in the form of the strtol prototype and a call to it, to warn about the fact that nptr and *endptr may alias in a way that triggers an undefined behaviour. Based on how I understood the latest draft n3096.pdf, it is the write to a char through *endptr (along with a read of that char through nptr) that triggers the violation of the 'restrict' clause. The read and write need not be in a particular order. No major compiler warns, though, as evident by an example at https://godbolt.org/z/a4xza5xna ------ What sort of optimizations can a strtol implementation hope to achieve? A couple of libcs discard the restrict qualifier when calling their handlers for strtol. The situation with strtol doesn't seem to be similar to that with memcpy-memmove. It seems that, as long as strtol does not assign a value to **endptr, it continues to adhere to the std. The historical docs point towards a decision to stamp the prototype with restrict under the assumption that (1) the string and the pointer to string are in disjoint memory locations, and (2) the implementations would use endptr for nothing else other than maintaining a position in the given string. -Amol > > Cheers, > Alex > > -- >