https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
--- Comment #2 from R. Diez <rdiezmail-gcc at yahoo dot de> --- > __FILE__ expands to whatever you pass on the command line as the base file > (and for headers whatever the directory is where they are found + the header > filename. So, if you compile with gcc -c something.c -I subdir/ , then > __FILE__ will be "something.c" or e.g. "subdir/something.h". If you use > absolute filenames, that is what you get. So, if you care about the lengths > of these, just tweak your Makefiles so that you do the right thing (compile > in the directory with the sources, with -o to the directory of object files > if different), rather than compiling in the object directory, with absolute > filenames as sources. Adding yet another __FILE__-like builtin preprocessor > constant is IMHO undesirable, I already wrote that I cannot easily control the path depth, because I am using the autotools in my project in order to generate the makefiles. Some libraries come with their own (complex) makefiles or build systems, so your advice is not practicable in real life. Moreover, the GCC toolchain itself decides where some of the include files lie and how their paths look. I also said that using absolute paths in the makefiles may be desirable for other reasons. I am concerned that the binary easily depends on the source code and toolchain location, which makes it hard to get a reproducible build. With __FILE__, there is no practicable solution. > especially in the spelling you're proposing. I do not actually mind about the spelling. I am just looking for some workable way (in real life) to include filename (source code position) information in assert messages that does not depend on full paths (and enables easily reproducible builds). > As for strrchr folding, I see it folded properly, e.g. __builtin_strrchr > (__FILE__, '/') is optimized into "foo/bar/baz.c" + 7. Optimizing it into > "baz.c" would be incorrect, you can do later on with the returned pointer > e.g. ptr -= 4; etc., which would be undefined behavior if everything before > the last / is removed from the string literal. OK, now I understand the issue with strrchr(), thanks.
