[llvm-bugs] [Bug 44480] New: __FILE__ is modified whenever "#include __FILE__" is encountered

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Jan 7 08:50:09 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=44480

            Bug ID: 44480
           Summary: __FILE__ is modified whenever "#include __FILE__" is
                    encountered
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: omoikane at uguu.org
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Created attachment 22994
  --> https://bugs.llvm.org/attachment.cgi?id=22994&action=edit
Demonstration of how __FILE__ is modified

Clang's preprocessor appears to prepend "./" to __FILE__ every time it
encounters "#include __FILE__" in a source code.  This can be observed by how 3
different strings are printed for this code:

  #ifndef INCLUDE_GUARD
  #define INCLUDE_GUARD
  #include <stdio.h>
  int main(int argc, char **argv)
  {
      puts(__FILE__);
      #include __FILE__
      puts(__FILE__);
      #include __FILE__
      puts(__FILE__);
      return 0;
  }
  #endif

https://gcc.godbolt.org/z/JTx2Np

If a piece of code manages to #include itself a finite but large number of
times, "#include __FILE__" will eventually fail because __FILE__ contains a
string longer than what's supported by the local file system.

The preprocessor should just keep __FILE__ constant.  Clang 3.5.1 and earlier
and all versions of GCC has the expected behavior, Clang 3.6 and later appears
to modify __FILE__.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200107/7031b667/attachment.html>


More information about the llvm-bugs mailing list