App security and the __FILE__ macro

The higher-ups decided we needed penetration testing of our app. One of their concerns was that if you run the macOS strings tool on our binary and grep for /Users, you get a ton of absolute paths for source files in the project. This is because (I think) we use the __FILE__ macro as part of our logging, to log file:line information. I find this info a boon, and we log that even in release builds to help track down issues reported by customers. At run time, we trim off all of the path except for the filename and extension.

It would be great if there were a __FILENAME__ macro that did this for me. Is there any such thing?


`strrchr(__FILE__, '/')+1` should get resolved at compile-time whenever you have optimizations on.

No kidding! I know we use code similar to that. I’ll have to check when I’m back at the computer.

I also need to find a solution for Swift, but that’s another list.

There's a patch waiting for attention here:

Looks like that would be great for you?

- Kim

It would, indeed. Too bad it's not in the current Xcode.

I'm using `strrchr("/" __FILE__, '/') + 1`. Should that also get resolved? I'm building now to see if this is even the reason the strings are popping up, but our build is long and complicated, so I'm not sure there's not some other source of the data.

Just have a look at a minimal example on godbolt:

Indeed the function call gets resolved at compile time. But that does
not mean that only the basename of __FILE__ is present in the binary.
No compiler that you can test on godbolt does this actually, neither
with -O3 nor with -Os.

And it's worse than that. We have a lot of third-party code that uses __FILE__ directly without trimming it. The best solution really would be a command-line option to modify the behavior of __FILE__. I hope the patch makes it in. I'm going to recommend a similar one for Swift.