Author Topic: header file exposure  (Read 3301 times)

0 Members and 1 Guest are viewing this topic.

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 4184
Re: header file exposure
« Reply #25 on: October 08, 2021, 08:17:17 pm »
Quote
You can check this with GCC

That's what made me think of it - I got caught with exactly this issue the other day when including a private header in a unit test module.
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 1584
  • Country: gb
Re: header file exposure
« Reply #26 on: October 09, 2021, 12:59:15 am »
it also goes wrong with Linux. When people redefine a critical constant and things start breaking but not immediately because for some weird reasons there is still the old definition around and it's the right order. But then someone removes the file and the kernel compiles but it doesn't even show a line on the console ...

... that is precisely when C is "funny" :D

I wasted two weeks on such a stupid thing, because I had no idea that was the problem, so I checked other things.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 16647
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: header file exposure
« Reply #27 on: October 09, 2021, 07:25:56 am »
I'm not making it super idiot proof, it only for future idiot me. If someone wants to include my file in the future I would at least expect them to read it and the first line will say that it is private to the C file it belongs to.
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 4184
Re: header file exposure
« Reply #28 on: October 09, 2021, 09:57:30 am »
Quote
I'm not making it super idiot proof

Well, quite. This kind of thing should be aimed at preventing accidental or unwitting screwups. There has to be an assumption that the user is at least semi-competent, and if he isn't then that's his problem. We ain't the police or bodyguards.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 9146
  • Country: fr
Re: header file exposure
« Reply #29 on: October 09, 2021, 05:48:19 pm »
There could have been a way using the preprocessor - at least with GCC.
GCC has a number of non-standard predefined macros. The one which could help here is '__BASE_FILE__'. Within the scope of an included file, it holds the name of the base file - the file that includes it.

It's unfortunate though that you can't use string literals in preprocessor comparisons.
Something like this, placed in the header file in question, assuming the .c file in which it's only allowed to be included is name 'allowed.c', would have been a candidate:

Code: [Select]
#if __BASE_FILE__ != "allowed.c"
#error Included in the wrong file!
#endif

But the preprocessor can't use string literals in this context, so it just gives an error (token ""allowed.c"" is not valid in preprocessor expressions). That's too bad.

Now if you can find a clever way of using this '__BASE_FILE__' macro to achieve the same result, there you go...


 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 4184
Re: header file exposure
« Reply #30 on: October 09, 2021, 06:12:35 pm »
Quote
a way using the preprocessor - at least with GCC.

I think using a compiler-specific feature may cause more problems than it solves. Whatever solution is used (even if that's "DNF") it needs to work with any standard-compliant compiler, and hopefully most that are more-or-less C.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 9146
  • Country: fr
Re: header file exposure
« Reply #31 on: October 09, 2021, 07:21:09 pm »
Now a simple approach not requiring anything non-standard would just be the following:

Add this in the header file 'xxxx.h':

Code: [Select]
#ifndef ALLOWED_FILE
#error Included in the wrong file!
#endif

To include it in another file:
Code: [Select]
#define ALLOWED_FILE
#include "xxxx.h"

Failing to define the 'ALLOWED_FILE' macro (name it as appropriate) before including the header file will yield an error.
So to include it, you have to explicitely define this macro. That should be enough to prevent unintended including, and would further self-document where it is appropriate to include it.
 

Offline Simon

  • Global Moderator
  • *****
  • Posts: 16647
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: header file exposure
« Reply #32 on: October 09, 2021, 08:26:27 pm »
I don't really need to guard from it being included by mistake.
 

Online dunkemhigh

  • Super Contributor
  • ***
  • Posts: 4184
Re: header file exposure
« Reply #33 on: October 10, 2021, 10:52:32 am »
Quote
That should be enough to prevent unintended including, and would further self-document where it is appropriate to include it.

I reckon that passes the test :)
 

Offline gnif

  • Administrator
  • *****
  • Posts: 1361
  • Country: au
Re: header file exposure
« Reply #34 on: October 12, 2021, 04:03:55 am »
Might have already been mentioned here but what I do is take advantage of the include directory flags for the pre-processor. Ie

Code: [Select]
project
 - module1
   - module1.c
   - internal1.h
 - module2
   - module2.c
   - internal2.h
 - include
   - public.h

Assuming gcc... `gcc -c -Iinclude module1/module1.c -o module1/module1.o`
Because the private internal header of module2 is not in the include path, unless someone uses a nasty `../` in their include path they can't directly access the private header of another module.
HostFission - Full Server Monitoring and Management Solutions.
https://hostfission.com/
https://twitter.com/HostFission
https://twitter.com/Geoffrey_McRae
 
The following users thanked this post: DiTBho

Offline Jan Audio

  • Frequent Contributor
  • **
  • Posts: 820
  • Country: nl
Re: header file exposure
« Reply #35 on: October 18, 2021, 01:43:21 pm »
Very funny.
You want not use long names, instead you want short defines, and you are worryd that they overrule some other define.

1 : Are you really typing ?, i use ctrl C + V mostly.
2 : You want two of the same defines that each file have a different function for the define, confusing.
3 : Programming most time-consuming and most-difficult task is making names for your variables.
You can instantly spot amateur code by the defines or no defines at all.

My advantage is i can use two languages for defines and variables.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf