public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: msebor@gmail.com
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Spurious warning for zero-sized array parameters to a function
Date: Fri, 9 Dec 2022 13:04:13 -0700	[thread overview]
Message-ID: <AA859385-52FD-46F1-A637-C98E79D6BFDF@gmail.com> (raw)
In-Reply-To: <55aaeff6-11ad-b7e5-1e81-bee6edc606e4@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6511 bytes --]

> On Dec 6, 2022, at 9:22 AM, Alejandro Colomar via Gcc <gcc@gcc.gnu.org> wrote:
> 
> Hi!
> 
> In the following function, past_end is a pointer to one-past-the-end of the array.  Holding such a pointer is legal in C.  I use it as a sentinel value that helps (1) avoid overrunning the buffer, and (2) detect truncation.  I mark it as having a size of [0], which clearly states that it can't be dereferenced (and as you can see, I don't).
> 
> /*
> * This function copies an unterminated string into a string.
> * -  It never overruns the dest buffer.
> * -  It can be chained, to concatenate strings.
> * -  It detects truncation.
> * -  Truncation only needs to be tested once after all concatenations.
> * -  The name is self-documenting, compared to its alternative: strncat(3).
> */
> char *
> ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
> {
>    bool       trunc;
>    char       *end;
>    ptrdiff_t  len;
> 
>    if (dst == past_end)
>        return past_end;
> 
>    trunc = false;
>    len = strnlen(src, n);
>    if (len > past_end - dst - 1) {
>        len = past_end - dst - 1;
>        trunc = true;
>    }
> 
>    end = mempcpy(dst, src, len);
>    *end = '\0';
> 
>    return trunc ? past_end : end;
> }
> 
> 
> If I compile the code above, GCC considers the function definition to be fine. However, at call site, it always warns:
> 
> 
> #define nitems(arr)  (sizeof((arr)) / sizeof((arr)[0]))
> 
> int
> main(void)
> {
>    char pre[4] = "pre.";
>    char *post = ".post";
>    char *src = "some-long-body.post";
>    char dest[100];
>        char *p, *past_end;
> 
>    past_end = dest + nitems(dest);
>    p = dest;
>    p = ustr2stpe(p, pre, nitems(pre), past_end);
>    p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
>    p = ustr2stpe(p, "", 0, past_end);
>    if (p == past_end)
>        fprintf(stderr, "truncation\n");
> 
>    puts(dest);  // "pre.some-long-body"
> }
> 
> 
> 
> $ cc -Wall -Wextra ustr2stpe.c
> ustr2stpe.c: In function ‘main’:
> ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0 [-Wstringop-overflow=]
>   43 |         p = ustr2stpe(p, pre, nitems(pre), past_end);
>      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
>   10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
>      | ^~~~~~~~~
> ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0 [-Wstringop-overflow=]
>   44 |         p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
>      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
>   10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
>      | ^~~~~~~~~
> ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0 [-Wstringop-overflow=]
>   45 |         p = ustr2stpe(p, "", 0, past_end);
>      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
>   10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
>      | ^~~~~~~~~
> ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0 [-Wstringop-overflow=]
>   43 |         p = ustr2stpe(p, pre, nitems(pre), past_end);
>      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
>   10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
>      | ^~~~~~~~~
> ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0 [-Wstringop-overflow=]
>   44 |         p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
>      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
>   10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
>      | ^~~~~~~~~
> ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0 [-Wstringop-overflow=]
>   45 |         p = ustr2stpe(p, "", 0, past_end);
>      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
> ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
>   10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
>      | ^~~~~~~~~
> 
> 
> The warnings are invalid.  While it's true that I'm referencing a pointer of size 0, it's false that I'm "accessing 1 byte" in that region.  I guess this is all about the bogus design of 'static' in ISO C, where you can have an array parameter of size 0, which is very useful in cases like this one.

Most of these warnings are designed to find simple mistakes in common use cases so "tricky," unusual, or otherwise unexpected code is likely to lead to surprises.  This warning expects that in calls to a function, every parameter declared using the array syntax (which is expected to have a nonzero bound) is passed a dereferenceable pointer as an argument.  It considers neither the definition of the function to see if it does in fact dereference the argument, nor this unlikely (and strictly invalid) use case.

The warning should not be issued if the parameter is declared as an ordinary pointer so I would suggest to use that instead.  It's possible that declaring the array parameter with attribute access none might also suppress the warning, but there is no utility in using a zero-length array in this context.  The intended purpose of the zero-length array GCC extension is as trailing members of structs in legacy (pre-C99 code) that cannot use flexible array members.  Using them anywhere else is likely to be surprising, both to tools and to readers, so the attribute on a pointer parameter would be preferable.

Martin

> 
> Cheers,
> 
> Alex
> 
> 
> -- 
> <http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP_signature --]
[-- Type: application/octet-stream, Size: 833 bytes --]

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmOPa2EACgkQnowa+77/
2zLF6g/9HwjlNrqNgUaX44/834zxY19e53rVCZ7mY1WWXa+mYOWjXEpgic0gG0+e
2n6YjJGGbZNsQs5e8DNwnq+XG0sr4ZWzAQR2tiADXPx9khBGZaoD2NsTUk5Nm6S1
pFrVACkD9FXmOzPpm15m1/MyFA0TfR60NNlxJFP+tgB3Pc+MX521xY+7ekDfRJkf
oNlvlbdq0DovkQSP5TJRu71CtP80WNZdbefj6fseaGjHJVNg/Dx76Y+uRE51p7Te
ZJtvEILAu8h775sjtSxwNFM5IPeudA5FPJaP1BOffnhXFVO4ncVtiVJsre2CM+AZ
lCFf9sYWX3KbYPFEwwmTIYCBDtuju4hZjrFvwvHywfgIKaiTMriBxnT3OCEVXI72
rZOZlvZpSwnf9EuKJ0UFdXgYwi8/OeB+wwh9+AfdkIuEQLZ8Qt/CJOcsnEaS5I1D
nmi9xifcPSvF7FAb9Ugjkw44KRPttRwrGUSK2lK14/Al/z6yngf+UFmsPcYDV8pH
NiJg2vwQ6Ovf75ua36afittM1fpj9Bwwefo1cQWbvHcbShMRjuu50Lq2ArWQFN1B
5FYoY5Cl3YR9AatITkPWEpb5l0A+Z4KK0kanmQVSIAiGyzc/bLivTOg0nvCb8HKj
5+RnCx7m4q+ATrwRX4qcho3E/YuT1FN/KYw+vCmn+F4fDzizqvM=
=3WDu
-----END PGP SIGNATURE-----

  parent reply	other threads:[~2022-12-09 20:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06 16:18 Alejandro Colomar
2022-12-07  8:17 ` Richard Biener
2022-12-09 17:15   ` Alejandro Colomar
2022-12-09 20:04 ` msebor [this message]
2022-12-09 20:19   ` Alejandro Colomar
2022-12-09 20:21     ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AA859385-52FD-46F1-A637-C98E79D6BFDF@gmail.com \
    --to=msebor@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).