Morris Keesan
4/3/2011 3:16:00 AM
On Sat, 02 Apr 2011 20:03:48 -0400, David Sudolcan <funbotix@yahoo.com>
wrote:
> I can't figure out why PC-Lint complains about the following code.
> Can you help? I have the following code in a header file.
>
> #ifndef _THIS_HEADER_FILE
> #define _THIS_HEADER_FILE
>
> typedef enum
> {
> RESULT_ERROR = -1,
> RESULT_PASS = 0,
> RESULT_BUSY = 1,
> RESULT_FAIL = 2
> }result_t;
>
> #endif
>
> And I have a different header file that has this in it.
>
> #ifndef _THAT_HEADER_FILE
> #define _THAT_HEADER_FILE
>
> typedef struct
> {
> result_t (*function1)(void);
> result_t (*function2)(int);
> }interface_t;
>
> #endif
>
> And I have a source file that includes the above header files (first
> 'this', then 'that'), and PC-Lint complains about the lines in the 2nd
> header file, as shown below.
....
>
> Is there something wrong with the way I'm trying to make this work?
I don't know PC-Lint, but in my opinion, there are two things wrong with
the way you're trying to make this work.
1: Instead of requiring other source files to always include this and that
in the correct order, you should simply have
#include "this.h"
at the beginning of "that.h". That way, you're guaranteed that result_t
is defined before you try to use it. And because you have the contents
of this.h protected with the #ifndef, there's no harm done if source.c
does #include this.h, whether it's before or after that.h
2: Get rid of the underscores at the beginning of THIS_HEADER_FILE and
THAT_HEADER_FILE. Identifiers beginning with an underscore followed by an
uppercase letter are reserved (see ISO C99 7.1.3, which also says that if
a program "defines a reserved identifier as a macro name, the behavior is
undefined." You're probably using these underscores because you've seen
other people do it, and/or because you or they have seen macros like this
in system header files. These macros in system (or compiler) header files
begin with underscores specifically because those names are reserved, and
the underscores keep those identifiers from conflicting with macros
defined in properly-written programs. By beginning your own macro names
with leading underscores, you're explicitly removing that protection from
your program.
--
Morris Keesan -- mkeesan@post.harvard.edu