The right way to define a C function with no arguments

When using GCC, why not use -Werror=deprecated-non-prototype to force an error? I guess using void is only good when you write your library and to avoid warning generation upon including your header files by end users, in case they have -Wstrict-prototypes, you should forcibly use VOID

c doesnt support overloading, so i assume that exactly one quantity of arguments and one specific type per argument is the only valid input. should i spend an infinite number of days per function explicitly declaring that my function(int) should not accept an infinite quantity of an infinite number of types?

In many (most) other C-looking languages an empy parameter list implies `void` and there is no explicit `void` which doesn't make it any easier to put it in. :)

💗🙌🏽

But what do I do about the void in my heart? I crash when trying to accept something new...

PARAMETERS NOT ARGUMENTS

Can you make videos on pattern matching algorithms in c

I would love to see a video on how you have vscode set up.

Besides omitting the 'void', I never put the 'int' before a function. I just do a function as: function() or function(int var1, unsigned char var2). Has never been an issue in the many C compilers I have used in over 30 years. What am I at risk for here?

So... Where did the 12 go??

My question is why doesn't no arguments imply a void argument since that's what everyone expects anyway? Can you even use the number argument you gave it for anything?

great tip! great to know this nuance... thanks!

Where are your clips that give us guidance on how to achieve software pipelining by using the restrict keyword? I'm thinking of making the compiler prepare for vector instructions.

ok, now you need a video on how to do a function like printf. something that uses variable number of arguments.

why? because sooner or later going to run into a situation where you don't have a choice of what tools you have or can pay for or administratively approved of.

cason point:
had a rad tool (rapid application development)
found the opening and closing the files would sometimes not close the file properly. this led to problems with trying to delete a file that it thought was already opened thus leading to a failure (Windows platform) The bad party is it would randomly not close a file for some reason unknown to us and we couldn't figure out what the issue was.

fortunately said rad tool, could make calls to the windows API functions.
so I found C type fopen() and freed() were in those API functions.I included our own reads and rights using that in the RAD tool. fortunately they did open and close the files properly.

And that's why C++ is better and you always compile with warnings as errors.

f() means you can pass ANY unspecified list of arguments to a functions and it will work, at least for some time, until you stop function args polymorphism. Do not shoot yourself in your foot

That was helpful, thanks for the video. On a related note, should functions always return a value? Or is it ok, or perhaps even preferred, to have: void fn(void) { // some code }?

Please make a video on working of vtables.

The problem with your recommendation to use (void) is that it's just visual clutter; it does not help reading the code. A better recommendation is to use option '-std=gnu2x' (with both gcc and clang); then you can simplify all the (void) clutter to () AND get decent diagnostics at the same time.

I was unaware of the difference, but let's be real: any decent compiler will give you that warning, which you should read. And even if it didn't, it should change absolutely nothing. If anything, the extra arguments you pass in will be copied to registers that the function will completely ignore. If you get lucky, the compiler will see that and just remove them for you altogether, I have no reason to believe something could possibly go wrong here

So how do you get access to arguments if they are not declared?

Does this apply to main()?

Begs the question: is there a use case for ommitting the explicit `void`? Maybe for calling a function via pointer, where args are optional depending on what function is called at runtime? Suppose the compiler couldn't warn against that anyway, though

This is one of the design choices that just doesn't make sense to me. Why would a function with no parameters be able to accept parameters if it wouldn't be able to do anything with them?

Personally, I hate K&R style and I avoid it even when I write C++. In other words, I explicitly use void in the function declarations and definitions of any function that takes no arguments, with the only exceptions being constructors because the stupid compiler gives me guff there. If the committee wants to formalize that C++ idiom for C23 then they can get wrecked.

but why initially C was designed to have this option of 0 or more arguments? As far as I know C has an implementation of variadic function using ...notation.

Pro tips: Since C23, the void is no longer needed. Next: Use compiler warnings and don't ignore them. Next: Compile your C code by a C++ compiler, it will find bugs in your code (and write only C code that is compatible with both C and C++).

I always aim for zero warnings at compile time. So this is not a big deal for me. 🤷‍♂

Beating video, thanks, one interesting thing that is missing is to how can we leverage "no or more arguments" in their function?

What about main?

I cannot believe you don't use gnu style brace placement, smh

How would you use the "zero or more arguments" in an empty set of parentheses? Is there a way to capture an arbitrary set of arguments not defined in the parentheses?
If there's no way to capture the arguments, then why is it a thing?

All companies I have been have a rule that a function can’t have an empty arguments parameter list. It shall always have a void or the actual signature of the function

So... f() implies that there should be no arguments.
and f(void) enforces that there must be no arguments?

I want that shirt..
Where did ya get it?

why a program compiled with int main(void) execute normally sending arguments

I'm the 23rd to mention C23

So does that mean all C functions can take varargs by default unless they have explicitly stated arguments, it's just that you can't access the arguments because you have no variable name to identify them by? Could you still access them with inline assembly assuming the compiler will still pass the arguments in to the function in the registers as usual?

Anyone with sense already uses -Werror, so they're the same after all. And anyone with weird warnings he has to ignore, preventing him from doing this, I'm sorry.

If you don't put void as the input to the function, and you just put 12, yet it still compiles and runs even though it's just a warning, I wonder what happens to that 12? does it just get discarded? is it actually put somewhere on stack frame? Does it depend on the sys architecture? Does it depend on the compiler? Maybe both?

"0 or more arguments" how exactly would those "more" be accessed? I'm assuming it's the precursor to ... for va_list so how?

"foo() means 0 or more arguments." Can the function in any way make use of those 'optional' parameters? Or does the compiler simply ignore those parameters? And if not, what happens to the call-stack in this scenario?

By the way, in "The C programming language" (best programming textbook) they explain why this is the way it is. Function arguments were declared inside the body before the standard used in the book was adopted, so that's another relic of backwards compatibility

If foo() can accept 0 or more arguments how do I access them

This video actually helped me even though I wasn't getting any compiler warnings (and I have all warnings set to on). In my code I was setting a function pointer of type (void) to a function with () arguments.

Hadn't caused any bugs for me yet but happy to have picked up the problem before it became a problem!

You could also have showed if generated assembly/binary is different.

This does not matter if -Wall -Werror flags are used, which should be always used IMO.