"Proper" way to declare functions 2

[JasonWB007]

Hi everyone,

I hope this isn't too elementary for everyone, but what is the absolute strictest "proper" way to declare a C function and to access it in a separate file? Assume I have been sent to a military Catholic school for C programmers (Actually, we're looking at DO-178, something much stricter The options I have considered (so far) are:

1. Declare the function prototype in the beginning of the source file where it is defined. Declare the function as
"extern ..." in the beginning of every other C file where it is used.

2. Declare the function prototype in the header file of the same name as the C file where it is defined. Include that header file in every C file that accesses the function.

Any other suggestions? Option #1 has the disadvantage that there is no guarantee that the "extern" declaration in the other C files is correct. Option #2 has the disadvantage that sometimes I do not wish to have all of the information contained within the function's header file made available to every other C file that needs access to just that one function.

This seems to be a question on data hiding or something like that. What do you all think?

Thanks much!

Jason

 

[DaveSinkula]

I generally go with #2, but only have the "public" functions in the header; any "private" functions are then static to the module.

What is an example of "all of the information contained within the function's header file"? Generally it should only be necessary data types and such: declarations. Making opaque types can be a bit more work, but it can be done to hide details on the data types.

 

[ArkM]

Try #2.5 approach:
Group all interfaces (app-wide scope prototypes and typedefs) in header files by themes. Make 'implementation' headers if you need (when you split the implementation for maintenance reasons) and use them in 'subsystem root' modules only.
In other words, better use mymath.h than mysqrt.h and mysin.h.
Of course, you may use static functions (and its prototypes) and local types in your modules w/o any headers.

 

[xwb]

I agree with ArkM. Also, the header file should be able to stand alone: you shouldn't need to include anything before it. It cuts down the number of files you have to modify when the dependencies change.

Also note that structure names can be forward declared as long as they are not passed by value. If a structure is used as a handle and its content only needs to be known in the implementation file, then there is no need to include it in the header.

 

[WebDrake]

Option #2 has the disadvantage that sometimes I do not wish to have all of the information contained within the function's header file made available to every other C file that needs access to just that one function.

I don't see why this is a problem. You will include header files like <math.h> or <stdlib.h> or <stdio.h> while only using a fraction of their available functions. Why worry about those you have written yourself?

 

[JasonWB007]

Thanks for all the replies. I think I like option #2.5 as well. However, I have always tried to keep one header file with one C file - it sounds like you are implying that this is not the best case? I don't quite know what you mean by "subsystem root", though. Could you explain?

Also, the reason I don't wish to have all of the information from headers available is probably because I have info in there that should be in the C source file (according to what I am reading here).

Based on the previous post, would you all recommend declaring EVERY function within a C file as "static" if you don't want other modules to access it? I mean, most code I have seen does not do that, but remember, I am trying to be as strict as possible for testability and certification reasons.

Thanks again!

Jason

 

[Salem]

> made available to every other C file that needs access to just that one function.
If you have small header files which strictly implement one interface, then the chance of including a header file just to get one function is minimal.

> declaring EVERY function within a C file as "static" if you don't want other modules to access it?
Certainly no reason not to (except for lousy debuggers and linkers which don't export static symbols properly).

Check whether your tools support meaningful debugging. It's all very well being pure, but you'll have a hard time developing and testing if the tools don't cooperate too well.

> I am trying to be as strict as possible for testability and certification reasons.
This will help a lot -

http://www.gimpel.com/

For example, your previous comment, it will find functions which could be static.
It has wide support for many compilers, and some coding standards (eg. MISRA-C)

For 'gestapo' mode, try

http://www.splint.org/

Just writing "hello world" is hard work ;-)

--