time.h(145): _CRT_INSECURE_DEPRECATE_GLOBALS _CRTIMP __checkReturn
int* __cdecl __daylight(void); I'm trying to compile my project under VC8 for the first time. This error appears to be caused by the macros _CRT_INSECURE... and/or _CRTIMP and/or __checkReturn. Anyone have any idea why these would cause a problem in the standard library headers I get several of these in a row all surrounding lines containing these macros.Thanks,
John
time.h(145) : error C2144: syntax error : 'int' should be preceded by ';'
Buddhike de Silva
Nikola - thanks for the feedback - you actually gave me the answer without realizing it. You see, the project I'm attempting to build is our System Abstraction Layer, the primary header file is named sal.h - so my header file name is conflicting with Microsoft's. I've been meaning to rename this file to nsal.h (for Novell System Abstraction Layer) anyway, so I think this is a good opportunity to do so.
Thanks so much,
John Calcote
Sr. Software Engineer
Novell, Inc.
JasonSacks
I cannot repro this bug with beta 2. __checkReturn is SAL annotation, defined in sal.h in vc\include, sal.h included in crtdefs.h and other, so you should not be seeing this error. Most likely this is some kind of broken installation or Beta 2 headers mixed up with Beta 1.
What is the smallest repro code that you can get this error
Thanks,
Nikola
VC++
Jani Holopainen
Additional information:
I preprocessed the file to STDOUT with no line numbers, and captured the output. Then I compiled that file alone. Here's the line that fails now:
__declspec(deprecated) __declspec(dllimport) __checkReturn int* __cdecl __daylight(void);
It appears the the __checkReturn macro is not getting defined anywhere before this point (or else it would not be displayed as __checkReturn). This may or may not be okay - I don't know if this is a keyword, or a macro. In either case, however, the error message seems to indicate that __checkReturn is an unknown quantity. Just to be sure, I placed this line right above the faulty line in the input file:
int abc(void);
Since compilation didn't stop on this use of 'int', I can only assume that the problem is not caused by a missing ';' above the faulty line.