EAX Register

[ejeffrey]

int main() and main() are the same thing.  In C the return type is int by defailt if it isn't specified.  Not just for main but for all functions.

[BitsnBytes]

int main() and main() are the same thing.  In C the return type is int by defailt if it isn't specified.  Not just for main but for all functions.

Yeah you are right, but the compilers needs the data type to be explicitly written to main() for successful compilation. int with main() only has this role and no other role in microcontrollers!

[SiliconWizard]

int main() and main() are the same thing.  In C the return type is int by defailt if it isn't specified.  Not just for main but for all functions.

Yeah you are right, but the compilers needs the data type to be explicitly written to main() for successful compilation. int with main() only has this role and no other role in microcontrollers!

What I think ejeffrey means here is that defining the function as simply 'main()' is equivalent to 'int main(void)'. And... they probably implied by that that it saves a few keystrokes and having to care about the return value.

But... default return types for function definitions is not part of the C standard anymore (since C99). There is no mention of that in C99 and later standards. It was allowed in C89.
Most compilers supporting C99 or later will accept this but will give you a warning.
This is deprecated and should IMO not be used.

[ejeffrey]

Yeah I was just replying to this:

According to my copy of The C Programming Language (Kernighan and Ritchie, 2nd ed), it's neither int main() or void main() but just main()

Not recommending that you make a habit of using implicit int return types.  I didn't realize that it was dropped from C99, but would not recommend it in any case.

[BitsnBytes]

Most compilers supporting C99 or later will accept this but will give you a warning

Ahhhh!

I was using _Bool, it was working in one computer and not working on my colleague computer.
Now I realized that may be his compiler is not C99 supported because _Bool is introduced in C99.

I was reading your post and it clicked in my mind 

[Siwastaja]

Make sure they look at the compiler help/documentation if they need to enable C99 support by some compiler flag; for example, in gcc, -std=c99.

If their compiler really does not support c99, I think that's a good reason to upgrade, that thing is over 20 years old now. Or is it some very exotic architecture?

Also, IMHO, _Bool is a stupid and inconvenient name, only picked to avoid clashes in old code bases. The idea is to include <stdbool.h> and use bool; do it if you can (i.e., you are writing new code, or your old code does not use bool, true or false as variable or type names).

[SiliconWizard]

Make sure they look at the compiler help/documentation if they need to enable C99 support by some compiler flag; for example, in gcc, -std=c99.

Yes, although gcc's default (so not needing explicit -std=c99) has been C99 for a long time now, so you shouldn't need to add the option... except for actually "downgrading" to C99, because the recent gcc versions have C11 as default. And by recent... it's actually been since version 6.x I believe (and we're at 10.x!), or maybe even 5.x?

To be accurate, the default now is actually not exactly C11, but a gnu-dialect of C11 (it adds specific gcc features on top of C11). An explicit "-std" option should restrict support to plain C standard, although I know some non-standard features are still supported with -std=cxx. For instance, attributes. I don't think they are part of the standard? (I may have missed that though.)

But unless you're using a very old gcc version, or you're willing to be very pedantic language-wise, you can safely use any C99 feature without explicitely setting the '-std' option.

Also, IMHO, _Bool is a stupid and inconvenient name, only picked to avoid clashes in old code bases. The idea is to include <stdbool.h> and use bool; do it if you can (i.e., you are writing new code, or your old code does not use bool, true or false as variable or type names).

Yeah. Absolutely. As you said, that was to avoid potential identifier clashes - especially since "bool" was actually a very popular identifier in old code bases. So, that may look ugly, but it's certainly not stupid.

But yes, you should prefer the standard headers and not directly use the underscore-prefixed identifiers if you can avoid them.

[BitsnBytes]

Make sure they look at the compiler help/documentation if they need to enable C99 support by some compiler flag; for example, in gcc, -std=c99.

Alright! thanks

[BitsnBytes]

But yes, you should prefer the standard headers and not directly use the underscore-prefixed identifiers if you can avoid them.

Yeah you are right and I was using MACROS for true and false using #define  I should have used stdbool.h

Please clarify _Bool is a specifier or identifier?

Regards

[SiliconWizard]

Please clarify _Bool is a specifier or identifier?

Not that it really matters, but _Bool is listed in the standard as a "type specifier" (along with void, char, int, etc.)
Identifiers are "user-defined", so what matters here is that you can consider _Bool as a keyword of the C language starting with C99. That means it's part of the core language, and is not itself defined in some header, or something.

As such, it has a specific behavior. It's not like an 'int'. Assignments to a _Bool variable can only result in '0' or '1' values. Its actual "size" is implementation-defined though. So it depends. You shouldn't rely on it. You can use sizeof() to see how big it is on your specific platform.

This '0' and '1' specificity is trickier than it looks, although in most cases you shouldn't make that matter. Let's see:
bool b = 10; // b will actually contain '1' after this assignment
BUT, as the _Bool type may actually hold a much larger range of values from a low-level point of view, it could contain something else that 0 or 1 if you use pointers to one and alias it with a different type. Don't mess with _Bool!

stdbool.h, OTOH, is just a thin (but standard) layer on top of it. It usually defines 'bool' either with a macro such as:
#define bool _Bool
or with a typedef:
typedef _Bool bool;

and additionally defines 'true' and 'false'.

[BitsnBytes]

Not that it really matters, but _Bool is listed in the standard as a "type specifier" (along with void, char, int, etc.)
Identifiers are "user-defined", so what matters here is that you can consider _Bool as a keyword of the C language starting with C99. That means it's part of the core language, and is not itself defined in some header, or something.

As such, it has a specific behavior. It's not like an 'int'. Assignments to a _Bool variable can only result in '0' or '1' values. Its actual "size" is implementation-defined though. So it depends. You shouldn't rely on it. You can use sizeof() to see how big it is on your specific platform.

This '0' and '1' specificity is trickier than it looks, although in most cases you shouldn't make that matter. Let's see:
bool b = 10; // b will actually contain '1' after this assignment
BUT, as the _Bool type may actually hold a much larger range of values from a low-level point of view, it could contain something else that 0 or 1 if you use pointers to one and alias it with a different type. Don't mess with _Bool!

stdbool.h, OTOH, is just a thin (but standard) layer on top of it. It usually defines 'bool' either with a macro such as:
#define bool _Bool
or with a typedef:
typedef _Bool bool;

and additionally defines 'true' and 'false'.

It is of 8 bits. Yeah I have started using standard library stdbool.h

Regards

[ejeffrey]

To be accurate, the default now is actually not exactly C11, but a gnu-dialect of C11 (it adds specific gcc features on top of C11). An explicit "-std" option should restrict support to plain C standard, although I know some non-standard features are still supported with -std=cxx. For instance, attributes. I don't think they are part of the standard? (I may have missed that though.)

The -std= option makes gcc standards compliant which means it disables extensions that conflict with the standard, I.e. those that would break a standards compliant program.  Double underscore words like attributes are reserved by the standard for implementations so they are still allowed.  In some cases gnu extensions can be spelled with and without underscores and the std=cxx option disables only the version without underscores.