On jueves, 16 de noviembre de 2017 13:22:00 -03 Ximin Luo wrote:
[snip]
> I pointed to the various C standards documents, as well as documentation
> from multiple compilers, stating that __FILE__ is the "name of the source
> file" and in no way guarantees that the expansion can later be re-used as
By the way: is there a macro or combination of macros which *default* value
can be replaced in the use of __FILE__ without caussing regressions?
Because if that's the case it's easier to convince upstream people that
changing the usage goes in favor of reproducibility without using strange up-
t
Explicitely CCing Guillem for this one.
On miércoles, 15 de noviembre de 2017 23:01:00 -03 Ximin Luo wrote:
[sip]
> The GCC patch (neither the previous nor the planned version) does not change
> the default behaviour of __FILE__, and was never intended to. Instead, it
> gives users the ability to
On miércoles, 15 de noviembre de 2017 20:35:00 -03 Ximin Luo wrote:
> Lisandro Damián Nicanor Pérez Meyer:
> > I was wanting to write this on a keyboard, but let me try on the phone and
> > see if we can all agree in one point.
> >
> > There is one *excellent* method to settle this once and foreve
El 15 nov. 2017 5:35 p.m., "Mattia Rizzolo" escribió:
On Wed, Nov 15, 2017 at 05:28:06PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
> There is one *excellent* method to settle this once and forever: submit
the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and whatever
> project
On Wed, Nov 15, 2017 at 05:28:06PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> There is one *excellent* method to settle this once and forever: submit the
> __FILE__ patch to GCC devs. If it gets accepted then Qt and whatever
> project is affected should change it.
It's forwarded, and it
I was wanting to write this on a keyboard, but let me try on the phone and
see if we can all agree in one point.
There is one *excellent* method to settle this once and forever: submit the
__FILE__ patch to GCC devs. If it gets accepted then Qt and whatever
project is affected should change it.
I
In data mercoledì 15 novembre 2017 20:14:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > 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 wordi
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 an
In data mercoledì 15 novembre 2017 12:09:00 CET, Ximin Luo ha scritto:
> Lisandro Damián Nicanor Pérez Meyer:
> > [..]
> >
> > Xi: you also mentioned that having to file hundreds of patchs seems
> > impossible. Well, it seems so, but it is actually not that necessary.
> > Please
> > allow me to
In data mercoledì 15 novembre 2017 10:57:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
> >> You're using __FILE__ inappropriately, none of the documentation
> >> guarantees or implies that you can access __FILE__ as a real
> >
El 15 nov. 2017 8:00 a.m., "Ximin Luo" escribió:
Pino Toscano:
> In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
>> You're using __FILE__ inappropriately, none of the documentation
>> guarantees or implies that you can access __FILE__ as a real
>> filesystem path. "Surely for
In data martedì 14 novembre 2017 13:47:56 CET, Holger Levsen ha scritto:
> On Tue, Nov 14, 2017 at 07:22:07AM +0100, Pino Toscano wrote:
> > > There are quite a lot of packages that use __FILE__ so forgive me for
> > > not checking every single use-case of it.
> >
> > This. When something is used
In data martedì 14 novembre 2017 11:14:00 CET, Ximin Luo ha scritto:
> You're using __FILE__ inappropriately, none of the documentation
> guarantees or implies that you can access __FILE__ as a real
> filesystem path. "Surely for relative paths" is your justification
> for your own broken behaviour
On Tue, Nov 14, 2017 at 07:22:07AM +0100, Pino Toscano wrote:
> > There are quite a lot of packages that use __FILE__ so forgive me for
> > not checking every single use-case of it.
>
> This. When something is used so widely, then changing its behaviour
> blindly is simply a no-no.
I tend to agr
On Tue, Nov 14, 2017 at 11:34:00AM +, Ximin Luo wrote:
> > Sorry, it is not realistic to force us to have a delta from upstream for no
> > direct gain.
> None of the solutions I suggested involve patching upstream, they would be
> done in d/rules.
"we do not only care about Debian but free s
In data lunedì 13 novembre 2017 23:44:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > [..]
> >
> > This is not an annoyance, it is the crux of the problem! __FILE__ is
> > something standard, with a very well defined behaviour, upon which
> > people rely on: you cannot trash it from one day to
On lunes, 13 de noviembre de 2017 23:44:00 -03 Ximin Luo wrote:
> Pino Toscano:
> > [..]
> >
> > This is not an annoyance, it is the crux of the problem! __FILE__ is
> > something standard, with a very well defined behaviour, upon which
> > people rely on: you cannot trash it from one day to anot
In data lunedì 13 novembre 2017 20:20:00 CET, Ximin Luo ha scritto:
> Pino Toscano:
> > [..]
> >
> > A better approach here is to work on removing the invalid & abusing
> > usages of __FILE__ from packages, just like it was done for __DATE__.
> >
>
> We in fact did not do the latter because it w
Processing control commands:
> severity -1 wishlist
Bug #876901 [qtbase5-dev] QFINDTESTDATA uses __FILE__
Bug #876917 [qtbase5-dev] QFINDTESTDATA uses __FILE__
Bug #876933 [qtbase5-dev] QFINDTESTDATA uses __FILE__
Severity set to 'wishlist' from 'normal'
Severity set to 'wishlist' from 'normal'
Se
20 matches
Mail list logo
