Pino Toscano: > [..] > >> In summary: in no document or standard, does it guarantee or imply >> that __FILE__ can be taken to represent a real filesystem path. >> Applications relying on this behaviour are broken and should not be >> upset when things don't work. As documented in multiple places, >> __FILE__ only has a very loose meaning, my patch fits within this >> loose meaning, and it is intended mostly for error messages. > > ... this is your own interpretation. Even if __FILE__ has a loose > meaning, you are still changing that small bit of meaning it has, > without even thinking twice. Also, where it is written that __FILE__ > is "only for error messages"? >
The loose meaning, indicates that programs should not rely on it for other meanings, and should be open to fixing themselves if implementations change their specifics. This is a general principle that applies to all text in all standards, it is not "my own interpretation". And stop twisting my words. You literally just misquoted me to advance your own point. I said "intended mostly for error messages": https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html "__FILE__ and __LINE__ are useful in generating an error message [..]" https://msdn.microsoft.com/en-us/library/027c4t2s.aspx "Without /FC, the diagnostic text would look similar to this diagnostic text:" The only examples I can find in compiler documentation of __FILE__ usage, is for error messages. There are no examples of any other usage. That strongly suggests it was originally intended for error messages and never intended to support file lookups. That's not the same thing as saying "it's intended only for error messages", but it does strongly imply that you shouldn't be surprised if your file lookups break with minor changes like my patch, and it certainly gives you no right to go off on a rant about me "breaking" stuff. http://c0x.coding-guidelines.com/6.10.8.html The presumed name of the current source file [..] https://software.intel.com/en-us/node/524489 Defined as a character string literal containing the name of the source file. https://www.ibm.com/support/knowledgecenter/SSAE4W_9.1.1/com.ibm.etools.iseries.langref.doc/ilcrefer13.htm A string literal representing the name of the file being compiled. You can even find threads online confirming __FILE__ is implementation-specific and not required by any standard to be a full path. You can even find threads of people complaining about the fact that __FILE__ sometimes has a full path, sometimes not - e.g. depending on what options you pass to the Microsoft compiler. Go do your own research about it. You need to get your facts straight before going on an ill-tempered rampage accusing me in bad faith of "not having a discussion" and being in "my own echo chamber". And stop pretending that my arguments are "my personal beliefs", they are not. And stop accusing me of blindly changing stuff against the standards, without knowing what the standards actually are. And stop accusing me of making my mind up before the discussion, when it is you that seems to have made up your mind before the discussion that I was "blindly" making changes and not thinking through consequences, I did think those through perfectly well thank you very much. And stop diverting the thread to making meta-comments about my word usage. It makes it seem like you're trying to make me look bad in front of an audience. I don't like playing those sorts of games, which is why I'm ignoring various other things you've been saying. And make some concrete proposals. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
