Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Code Reviews Meta
Q&A
Posts Tags Edits
Ask Question

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

71%
+3 −0
Q&A What are disadvantages of static functions (ie functions with internal linkage) in C?

There are some reasons why a function would intentionally not be declared static. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translati...

posted 1y ago by Dirk Herrmann‭  ·  edited 1y ago by Dirk Herrmann‭

Answer
#4: Post edited by user avatar Dirk Herrmann‭ · 2023-07-10T06:47:46Z (over 1 year ago)
Added note about unit-testing static functions and limitations due to special development tools.
  • There are some reasons why a function would intentionally not be declared `static`. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units.)
  • * The function is intended to be part of the public interface of some module/library. Then, the function would have to be given external linkage. In such a case, the respective function would, however, be declared in some public header file. Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
  • * The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library. In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file. This is a scenario where the simple distinction between internal and external linkage is not sufficient. In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library. But, this concept has no standard way of being expressed in the C language.
  • * A special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface. In this case, the function also needs to be given external linkage.
  • In practice, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept. I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`. Therefore, there must be an interest in having such checks in the tools...
  • There are some reasons why a function would intentionally not be declared `static`. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units. Moreover, the OP asked about functions, but the following also applies to variables in the same way.)
  • * The function is intended to be part of the public interface of some module/library. Then, the function would have to be given external linkage. In such a case, the respective function would, however, be declared in some public header file. Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
  • * The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library. In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file. This is a scenario where the simple distinction between internal and external linkage is not sufficient. In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library. But, this concept has no standard way of being expressed in the C language.
  • * A special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface. In this case, the function also needs to be given external linkage.
  • Some people think that making functions `static` makes it impossible to call them from unit tests. It is not impossible, but requires a bit of trickery: You have to `#include` the `.c` file with the `static` functions into the `.c` file that holds the unit-test code. This trick, however, is commonly known, fully compliant with the C standard and also applied by commercial unit-testing tools. Nevertheless, this possibility may come as a surprise to many developers coming from languages with module systems.
  • I also seem to remember that I was once working in a development context for embedded systems where some debugger had difficulties in handling static functions properly. It is quite some time ago in my case, but certainly when you are working in an environment with a very specific tool set you may even today encounter limitations of these tools.
  • But, after all, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept. I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`. Therefore, there must be an interest in having such checks in the tools...
#3: Post edited by user avatar Dirk Herrmann‭ · 2023-07-09T17:20:02Z (over 1 year ago)
  • There are some reasons why a function would intentionally not declared `static`. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units.)
  • * The function is intended to be part of the public interface of some module/library. Then, the function would have to be given external linkage. In such a case, the respective function would, however, be declared in some public header file. Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
  • * The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library. In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file. This is a scenario where the simple distinction between internal and external linkage is not sufficient. In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library. But, this concept has no standard way of being expressed in the C language.
  • * A special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface. In this case, the function also needs to be given external linkage.
  • In practice, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept. I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`. Therefore, there must be an interest in having such checks in the tools...
  • There are some reasons why a function would intentionally not be declared `static`. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units.)
  • * The function is intended to be part of the public interface of some module/library. Then, the function would have to be given external linkage. In such a case, the respective function would, however, be declared in some public header file. Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
  • * The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library. In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file. This is a scenario where the simple distinction between internal and external linkage is not sufficient. In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library. But, this concept has no standard way of being expressed in the C language.
  • * A special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface. In this case, the function also needs to be given external linkage.
  • In practice, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept. I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`. Therefore, there must be an interest in having such checks in the tools...
#2: Post edited by user avatar Dirk Herrmann‭ · 2023-07-09T17:17:07Z (over 1 year ago)
  • There are some reasons why a function would intentionally not declared `static`. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units.)
  • * The function is intended to be part of the public interface of some module/library. Then, the function would have to be given external linkage. In such a case, the respective function would, however, be declared in some public header file. Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
  • * The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library. In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file. This is a scenario where the simple distinction between internal and external linkage is not sufficient. In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library. But, this concept has no standard way of being expressed in the C language.
  • * There is one special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface. In this case, the function also needs to be given external linkage.
  • In practice, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept. I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`. Therefore, there must be an interest in having such checks in the tools...
  • There are some reasons why a function would intentionally not declared `static`. (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units.)
  • * The function is intended to be part of the public interface of some module/library. Then, the function would have to be given external linkage. In such a case, the respective function would, however, be declared in some public header file. Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
  • * The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library. In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file. This is a scenario where the simple distinction between internal and external linkage is not sufficient. In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library. But, this concept has no standard way of being expressed in the C language.
  • * A special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface. In this case, the function also needs to be given external linkage.
  • In practice, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept. I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`. Therefore, there must be an interest in having such checks in the tools...
#1: Initial revision by user avatar Dirk Herrmann‭ · 2023-07-09T17:16:02Z (over 1 year ago) 
There are some reasons why a function would intentionally not declared `static`.  (In the following I use the term 'module', but in contrast to others, I use it not to describe a file or translation unit, but rather for an architectural entity (for example, a library), which can consist of several source files / translation units.)

* The function is intended to be part of the public interface of some module/library.  Then, the function would have to be given external linkage.  In such a case, the respective function would, however, be declared in some public header file.  Since modules/libraries can be used without making use of all their functions, it is possible to observe situations where a function with external linkage is not used outside its own translation unit, but external linkage is nevertheless appropriate.
* The function is not part of the public interface of some module/library, but has to be shared among different translation units of the module/library.  In such a situation the function would be declared in an internal header file of the module/library that is not included directly or indirectly in the public header file.  This is a scenario where the simple distinction between internal and external linkage is not sufficient.  In case of shared libraries, however, there is the possibility to define which symbols shall be exported from the library.  But, this concept has no standard way of being expressed in the C language.
* There is one special case which is a bit of a mixture of the above two ones is, where a function is _not_ part of the public interface, but is used by a macro or inline function that is part of the public interface.  In this case, the function also needs to be given external linkage.

In practice, yes, it happens that developers simply forget to declare functions as `static` - or they may not even be familiar with the concept.  I would argue that this is not uncommon: First, forgetting to declare a function `static` happened to me as well :-), second, all static code analysis tools (no pun intended) that I have used had some checks to detect such situations and issue a warning to inform the developer about functions that could be declared `static`.  Therefore, there must be an interest in having such checks in the tools...