public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "luigighiron at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/114816] New: Non-standard behavior with void arguments
Date: Tue, 23 Apr 2024 03:58:53 +0000	[thread overview]
Message-ID: <bug-114816-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114816

            Bug ID: 114816
           Summary: Non-standard behavior with void arguments
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luigighiron at gmail dot com
  Target Milestone: ---

After thinking about qualified void return types I decided to think about void
function parameters:

> The special case of an unnamed parameter of type void as the only item in
> the list specifies that the function has no parameters.
Section 6.7.6.3 "Function declarators (including prototypes)" Paragraph 10
ISO/IEC 9899:2018

No other restrictions are present that would forbid void parameter types. GCC
seems to accept functions that use such arguments as long as they have names,
for example:

void a(void x);
void b(const void x,register void y,register volatile void z);

Are accepted by GCC, but the following declarations are not accepted by GCC
when they should be valid:

void c(void,void);
void d(const void);

Other incomplete types are accepted by GCC. Note that the type of the parameter
is const void and not void so d is a function taking an argument of type const
void and returning void, which means that the types of a and d are compatible.

The storage class register can be used on arguments and the same is true for
void arguments, which doesn't affect the type so the following program should
be valid:

int main(register void){}

Clang accepts this while GCC rejects. The storage class register doesn't affect
the type and it is still one unnamed parameter of type void so this should be a
declaration for zero arguments.

Calling any function with a void parameter is a constraint violation because of
the following contraint:

> If the expression that denotes the called function has a type that includes
> a prototype, the number of arguments shall agree with the number of
> parameters. Each argument shall have a type such that its value may be
> assigned to an object with the unqualified version of the type of its
> corresponding parameter.
Section 6.5.2.2 "Function calls" Paragraph 2 ISO/IEC 9899:2018

GCC does not diagnose the error and instead just interprets the first void
argument as being a sentinel value indicating when the arguments end, for
example with the function a from before GCC accepts calling it with zero
arguments. Qualified versions of void for example with the function b from
before are properly diagnosed.

When referencing a function type with a single void parameter GCC will omit the
name of the parameter as usual which leads to some confusing error messages,
for example:

void f(void x);
void f(void);

The error message indicates that these types are incompatible, but it describes
the first declaration as having type void(void). Here is the error output
omitting source locations:
> error: conflicting types for 'f'; have 'void(void)'
> void f(void);
>      ^
> note: previous declaration of 'f' with type 'void(void)'
> void f(void x);
>      ^

             reply	other threads:[~2024-04-23  3:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-23  3:58 luigighiron at gmail dot com [this message]
2024-04-23 12:06 ` [Bug c/114816] " jsm28 at gcc dot gnu.org

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=bug-114816-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).