Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c    |    Meh, in C you gotta define EVERYTHING    |    243,242 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 241,973 of 243,242    |
|    David Brown to Kenny McCormack    |
|    Re: Attributes on functions/variables (s    |
|    15 Nov 25 10:55:06    |
   
   From: david.brown@hesbynett.no   
      
   On 14/11/2025 15:20, Kenny McCormack wrote:   
   > Wow! An actual on-topic C question. Don't see much of that around here   
   > these days...   
   >   
   > My question has to do specifically with "static" - as seen below - but also   
   > in general with these sorts of attributes of functions and variables.   
   >   
   > Suppose I have code like this:   
   >   
   > /* static */ char *foo(int);   
   > int somefun(...) { code that uses foo() }   
   > ...   
   >   
   > static char *foo(int bar) { definition of foo() }   
   >   
   > Is foo() static or not? Does the order matter? Suppose the first reference   
   > to foo() had static and the second one didn't?   
   >   
   > Or is it a syntax error to have different declarations/definitions like   
   > this? What if they occur (as they usually will do) in different files (TUs)   
   ?   
   >   
   > Note that this came up in real life - I had to change a function that had   
   > been static to non-static and was concerned about what would happen if I   
   > didn't change it in every place. I didn't do much testing and decided to   
   > post here instead.   
   >   
      
   As Kaz said, it is UB to have a non-static declaration and then a later   
   static definition or declaration. Compilers are likely to treat that as   
   a hard error, though I am not sure that is strictly required by the   
   standards. But it means you are unlikely to be able to make this kind   
   of mistake without noticing!   
      
   (Slightly bizarrely, you are allowed to have a "static" declaration   
   followed later by an explicitly "extern" declaration or definition - the   
   result is static (internal) linkage. I'd far rather that inconsistency   
   was an error, but I guess it all goes back to historical reasons.)   
      
   It might not help when you are dealing with existing code, and might not   
   be ideal for all projects and code organisations, but I think a good   
   practice is that all "exports" for a file should be in "file.h". These   
   function declarations will obviously not be "static" (except perhaps   
   small static inline functions declared in the header), and can be   
   explicitly marked "extern" if you like. Then inside "file.c", you   
   include "file.h" and every function is either defined as "static" or   
   matches one of the exported functions in the header. I am not a fan of   
   forward static declarations unless they are absolutely necessary - they   
   are just a way to add effort to code writing and maintenance and a big   
   risk of inconsistency. But if you /do/ have a forward declaration in   
   "file.c", then you know it must always be "static".   
      
   And if you use gcc, you can enforce this with "-Wmissing-declarations"   
   "-Wredundant-decls".   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca