Bug#876901: QFINDTESTDATA uses __FILE__

[Pino Toscano]

In data mercoledì 15 novembre 2017 19:29:00 CET, Ximin Luo ha scritto:
> 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".

Loose meanings do not imply neither the other way around, that you are
free to break because people cannot do anything with it.  Also,
considering the very same behaviour (short of the different wording in
documentations) that is established for decades, this is a "de facto"
standard.

> And stop twisting my words. You literally just misquoted me to
> advance your own point. I said "intended mostly for error messages":

Point taken, but my argument remain: where it written it is "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.

These are just very short documentation snippets; these documentations
surely cannot cover all the cases, so the most prominent one is shown.

> 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,

Err no: the fact that something is not documented does not make it
automatically bad.  By this logic, __FILE__ would be the very last
problems in sources of modern software.

> and it certainly gives you no right to go off on a rant about me
> "breaking" stuff.

My rant replies to another rant about __FILE__... done by you.

> 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.

The texts above clearly said that __FILE__ contains the path passed to
the compiler, which is very different from saying it is purely
"implementation-defined".  I never claimed that __FILE__ is a full path
in all the cases.  Here you are misquoting what I said in previous
emails.

> You need to get your facts straight ...
> [...]

Please stop ad-hominem attacks.
Please stop ignoring other people's opinion.
And yes, please get out of your own echo chamber.

> And make some concrete proposals.

I already did, multiple times; alas, you discarded them a priori, since
they don't fit your own solution.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20171115/44f8d135/attachment.sig>