1

Let's suppose I am making a library in C, that contains functions api1(), api2(), and api3(). However, those functions are very complicated, so I need other functions to make them. Let's call those functions subfunc1(), subfunc2(), and subfunc3(). What I want is that the users of this library can only use api1,2,3() and not subfunc1,2,3(). I can't just declare them static, because I want to place api1,2,3() into api.c file, and subfunc1,2,3() into subfunc.c file.
So my questions are:

  • Is there any way to achieve this, besides including subfunc.c file into api.c file and declare subfunc1,2,3() as static?
  • If including subfunc.c file into api.c file is the only way to achieve this, is it recommended? Is it widely used in practice? If not, why?
Rachid K.
  • 4,490
  • 3
  • 11
  • 30
kjh6b6a68
  • 499
  • 2
  • 8
  • 2
    Make a `.h` file with prototypes of functions you want to be 'visible'. – Wouter Jan 28 '21 at 12:45
  • 2
    Do you care about the linker symbols? If no, make an internal header file and an external header file, so that the user of the library can only see the external prototypes. If yes, I would make the subfuncs static and in an extra header file as header only and include that. I would never include a c file. – mch Jan 28 '21 at 12:47
  • yes, i care about the linker symbols, and i tried making subfuncs static and put only function header in an extra header file and include them, but it's not working. – kjh6b6a68 Jan 28 '21 at 12:56
  • 3
    If you don't want the linker symbols visible, I'm afraid you have no choice other than declare the `subfunc*` functions static and put the all into the same .c file. But otherwise is it really a problem if `subfunc*` functions are visible to the linker? As you don't provide .h files for them nobody will ever call them. And if someone does anyway, it's not your problem. – Jabberwocky Jan 28 '21 at 13:02
  • 2
    Likely duplicate: https://stackoverflow.com/questions/435352/limiting-visibility-of-symbols-when-linking-shared-libraries I'll let others decide. – Andrew Henle Jan 28 '21 at 13:09
  • 1
    is there any reasons for avoiding incluidng .c files? – kjh6b6a68 Jan 28 '21 at 13:12
  • @kjh1918 good point. Usually including .c files is not encouraged, but for this particular case it's definitely an option. – Jabberwocky Jan 28 '21 at 13:14
  • 1
    Standard C does not provide a way to do this. There are ways depending on the linker you are using, or other aspects of the tool chain. You should state what tools and operating system you are using. – Eric Postpischil Jan 28 '21 at 13:29
  • @kjh1918 *"is there any reasons for avoiding incluidng .c files?"* - Yes! Don't ever do that. – klutt Jan 28 '21 at 14:05

1 Answers1

0

For others to use functions from your library, they need a header file that has all the function declarations of functions you want them to use.

So simply make a header file called [library name].h that has only the function declaration of functions you want to make public, and bundle it with your library files.

I haven't made much libraries my self, but from working with them, it is common practice to write documentation in the header file of how to use each function, and the less functions there are, the less confusing it is for the reader.

Jabberwocky
  • 48,281
  • 17
  • 65
  • 115
Any name works
  • 11
  • 3
  • 1
    He doesn't want the linker symbols be visible for whatever reason. Your English is good enough, no need to apologize. – Jabberwocky Jan 28 '21 at 13:04