Products > Programming

nesting of .h files and .h files which start with an underscore

(1/6) > >>

I am having problems compiling some code I got from someone else.

It isn't recognising time_t. In Cube, a right-click on that shows it declared in _timeval.h but that is not being #included anywhere. Presumably it is defined "somewhere" and probably as a .h inside another .h and possibly inside another .h. I never do that but a lot of ST libs do that. Doing esoteric stuff with .h files seems to be a "unix coder" way of separating men from sheep and I am sure books have been written on it :)

Is there a way to work out the dependency path which the compiler followed?

I have another one with uint64_t which is  in _stdint.h which I am also not #including. But that one is working... and I can't find how it is finding uint64_t as defined.

#include <time.h>?

Sure, it should be there but it isn't.

A right-click on time_t and "open declaration" points to _timeval.h which contains

typedef   _TIME_T_   time_t;

and doing that on _TIME_T_ takes one to _types.h and in there is

#define   _TIME_T_ __int_least64_t

which takes one to _default_types.h and in there is

typedef __INT_LEAST64_TYPE__ __int_least64_t;

which is a macro that expands to

long long int

But for some reason, while the IDE is apparently able to track up this ludicrous dependency chain (well, at least it does fish out a .h file where this is defined) the compiler can't.

There also appears to be some convention that .h files starting with an underscore have some special usage or meaning.

I am writing for a 32F4 ARM which is natively 32 bit so I am using uint8_t...uint64_t, rather than int, long, long long etc.

It doesn’t have to be there (assuming that by “there” you mean the time.h header). It has to be defined in the current compilation unit after the preprocessor expands time.h. That’s the only requirement. It may be in some other header included by time.h, it may even be magically provided by the compiler without ever being explicitly defined.(1)

If you have explicit #include <time.h> in your source code and the compiler complains it still doesn’t know what time_t is, it’s a bug in the compiler or the standard library it uses. I don’t have that particular toolset, so I can’t test to see what error you are receiving. But it is not up to you, as a programmer, to fix it: the compiler vendor should correct the issue. You may provide a temporary workaround in your code, if needed, but be aware this should be viewed only that way: as a temporary workaround. Tell us the exact error message you are receiving while trying to use time_t. For suggestions of a workaround, tell how that time_t is going to be used.

The IDE is not performing actual compilation. It may or may not execute a complete preprocessing stage (again, I can’t determine that), but its outcomes may be different from the actual compilation result due to different preprocessor defines. In any case, it’s performing some kind of guesswork and, very often in IDEs, that is finding either all matching definitions or just any of them. Not necessarily those, which would actually be used. Consider your IDE’s “find definition” feature to be glorified grep.

(all the above is also true for uint64_t, assuming that this type is available in that compiler(2))
(1) Which I haven’t seen for time_t, but some other built-in things happen to be provided that way.
(2) Presence of any uintN_t and intN_t type is always optional in C.

Yeah, it may very well be that <time.h> was included above "module.h" while the module depends on time objects.
When you reverse the include order you get an error, while in fact module.h should also have contained an include for time.h to be independent.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version