bool function declaration in header file. Codeblocks tells me I forgot to include stdbool.h
 

No includes in the header file for this source file.

Codeblocks

Current git. https://gitlab.com/jmgibson1981/mylibraries

Each of the errors in my build messages references the header file.

I don't see any reference to 'bool' in any of your header or source files there, so there must be some more code that is part of the project?

I was trying to test some. For the moment I changed them to int based 1 / 0 for true false. The sledgehammer approach I suppose.

For what it's worth I tried using _Bool but it didn't register that either.

Also for reference the only failure was in the header file.

I had 3 of these, 1 error for each. It went away when I manually added the stdbool.h to the header file itself but to my knowledge I shouldn't need to add anything to the header files other than the definitions of the functions.

All types used in the function declarations must be defined before the function is declared.

If you declare a function that returns a bool type then type bool must be defined before the function is declared. If you declare that function in a header file then stdbool.h must be included in the same scope as the header before the function is declared. Including it in the header file is one way to do that.

Added: My comments above considered only preprocessor/compiler errors. If as you clearly say, it is Codeblocks itself reporting the error then maybe it looks at each file in isolation (I do not use codeblocks so do not know what tests it performs). Either way, is there a reason you would not want to add that include to the header file?

But it was declared in the source file that the header belonged to? Shouldn't it have picked it up from there?
Especially as I had #include "header.h" after the standard libraries?

This is what I'm lost on. I figured the previous includes of the standard library stuff would pass through to any headers as my header is last on the list.

Calling it "pass thru" may be misleading, but each file is included as it is encountered and the result is called a translation unit, so the std includes which appear before the local header is included will be visible to the local header in the same translation unit.

But as you say it is a Codeblocks error it makes me think it is not a preprocessor/compiler error, but codeblocks itself which is producing the error and codeblocks might look at it differently, producing the error before the preprocessor sees the code. Can you clarify that?

I think the interdependence of headers and other files is usually called the coupling, and the idea is generally to have low coupling. That is, they should not be highly dependent the presence or ordering of other files but should stand alone as much as possible, and hence include the things they themselves depend on. Std headers are idempotent largely for this reason so including them more than once does not affect the result.

Ok. I'll define in each file as needed. So much to learn. Thank you.

This thread "seems strange" and I feel that the actual cause of the problem is somewhere beyond what you have showed us.

Fair enough. Here is the most recent changes where I made bool disappear.

https://gitlab.com/jmgibson1981/myli...7e9da17cfaac92

The only thing not included in the git was this.

You have compensated for the underlying "problem," through a slew of source-code changes that your successors will one day curse you for, because you did not in fact find it and solve it.

You "made 'the immediate problem' go away," but, because you did not in fact solve it: you made it perpetuate.

If I were a manager over any of your teams, I would immediately reject this branch and require you to do it all over again ... "properly." The presence and proper use of a bool data-type is entirely appropriate for this situation, and for the future of this code. You should not now be allowed(!) to "gloss over it." Go out there now and find the "root cause" of this problem. Don't offer a pull-candidate to me until you've found it.

I fully intend to change it back. I was testing the functionality. I couldn't find the reason after a day or so. Hence my post here. I was under the impression I wasn't supposed to put includes in the header file. Now that I know that I will be reverting.

*EDIT*

it is now done, also found other places to make the same change.

The alternative is putting all the includes in each C file, but includes in the header is the usual approach. https://go.dev/talks/2012/splash.article#TOC_5.

FYI, one usually doesn't have #ifndef guards in .c files (because you generally don't #include them anywhere).

It would probably be useful to you and informative to those offering help to understand where that impression came from. If you read that, or perhaps misunderstood something else to have that meaning, it is probably important to understand the context and if necessary adjust your understanding of what was actually intended.

A common use, in my experience the most common use, of header files is to provide the public interface of some particular module, library or application and this appears to be your use case. As such they should normally include everything they require without dependencies on the application source (again, part of the idea of "low or loose coupling" to other modules or files).

I got it from my own searching. When I had put the bool.h in the header it worked. But when I would google for the proper location of includes the only examples I ever found were at the top of the .c file. Even when I searched specifically for includes in headers it showed a header file with no includes and they were all in the .c file.

Just now changed all my includes to the headers and everything is fine. Just including the header file win my source file. I had it backwards I guess. I'm amazed anything worked before now.

Not necessarily, it isn't really about "right" and "wrong" ways of doing things, but rather finding out "how" each part affects others and organizing your own code to fit your use case.

Examples in books and online will often not show the includes just to shorten the example code. I would suggest having a look at a few header files on your system for a variety of real world examples.

The important thing to take away from this is not that you "fixed" it, but rather that you reorganized your code in a way that was more useful to your case. Take some time to pause and consider the effect of that change and work towards being able to make good choices for the task at hand.