..\display.h(72): warning: #231-D: declaration is not visible outside of function
I got message when I included a header file containing this line:
void DISPLAY_string_date_time(const struct tm * tim, DISPLAY_MSG * p_message);
I found the problem - I hadn't included <time.h> in the two cases that caused the warning.
After a lot of searching for what this warning means, I can't find any explanation.
Can anyone translate what the compiler is saying?
I would really be interested too. I can't directly see what source code error that would motivate the error message.
Something declared within a function is intended to be only visible within the function, so there should not be any warning.
Do you have any data types declared in any of your functions? In case the compiler saw tm being declared somewhere else in the code, it might have decided to be overly clever and warn that your undefined global tm use could not be matched with the local definition int saw somewhere else. But in that case, the compiler should have been so clever that it showed the other line number too.
That's probably because nothing has directly caused it; it is probably caused "indiectly" as a result of the compiler getting out-of-sync with the source text because of the original error(s) due to the missing header(s).
Here is the code. I have included the relevant bits of what's in the include file.
To clarify one more time, there are no errors. It is only a warning. It compiles and runs. But I can't check in code with warnings, so I had to find it.
#include <time.h> ...more struct tm { int tm_sec; /* seconds after the minute, 0 to 60 (0 - 60 allows for the occasional leap second) */ int tm_min; /* minutes after the hour, 0 to 59 */ int tm_hour; /* hours since midnight, 0 to 23 */ int tm_mday; /* day of the month, 1 to 31 */ int tm_mon; /* months since January, 0 to 11 */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday, 0 to 6 */ int tm_yday; /* days since January 1, 0 to 365 */ int tm_isdst; /* Daylight Savings Time flag */ union { /* ABI-required extra fields, in a variety of types */ struct { int __extra_1, __extra_2; }; struct { long __extra_1_long, __extra_2_long; }; struct { char *__extra_1_cptr, *__extra_2_cptr; }; struct { void *__extra_1_vptr, *__extra_2_vptr; }; }; }; ...more #include "display.h" ...more typedef struct { uint32_t x; uint32_t y; uint32_t size; uint32_t font; uint8_t text[24]; } DISPLAY_MSG; void DISPLAY_string_date_time(const struct tm * tim, DISPLAY_MSG * p_message); ...more
If I comment out <time.h>, I get the warning and a clean compile. With <time.h> in I don't get the warning.
I don't understand why I wouldn't just get an "Identifier undefined" type of error.
The reason I'm willing to try to find an answer is that I spent a lot of time searching for an explanation. If I understood why I got that error this time, I might find it faster next time. It would have taken 10 seconds to find if I had got an "Identifier undefined" error.
The function prototype declaration does not require knowledge about the size of "struct tm", so is allowed without the complete structure type definition being in scope. An error diagnostic would be unwarranted in this case (but compilers are allowed to warn about anything).
You are right.
The compiler makes a difference between:
int function(struct tm* t);
and
struct tm; int function(struct tm* t);
I haven't thought about this case before. I always have the second alternative, if I need to make use of a struct or class pointer without letting the header file see the full definition.
No. There are situations where this happens, and causes all kinds of weird messages from the compiler. But this is not one of them.
The warning message under discussion is fully justified, and its text points exactly at the problem.
Thanks Dan.
That makes perfect sense now. Life would be simpler if there were a place where the error message was explained with the two paragraphs you just wrote.
Yes, indeed - this has been noted before!
eg, my post of 4-Sep-2009 17:22 GMT in this thread: http://www.keil.com/forum/docs/thread15484.asp