Your message dated Sat, 9 Jan 2021 17:47:09 -0300
with message-id
<CA+QPbz3SRW306_o3FzYwpME36ZrPe1E9wB2OZ2U3=lcbyvj...@mail.gmail.com>
and subject line Re: Updating dpkg-buildflags to enable
reproducible=+fixfilepath by default
has caused the Debian Bug report #979570,
regarding dpkg: Breaks perfectly valid usage of __FILE__
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
979570: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979570
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: dpkg
Version: 1.20.6
Severity: serious
Justification: Breaks well defined functionality
X-Debbugs-Cc: [email protected],
[email protected]
Hi! As discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901
mangling __FILE__, even if for reproducible builds, breaks a perfectly valid
usage of __FILE__.
Please revert #974087 until someone provides a valid patch for QFINDTESTDATA
and it's well tested.
-- Package-specific info:
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf
Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8),
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Sat, 9 Jan 2021 at 16:52, Mattia Rizzolo <[email protected]> wrote:
>
> On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote:
> > Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300,
> > a ecrit:
> > > # __FILE__ is a public, well defined API
> >
> > ? My copy of C11 says
> >
> > “
> > __FILE__ The presumed name of the current source file (a character string
> > literal)
> > ”
> >
> > that's not so well-defined. I would not expect it to necessarily
> > contain the path to it.
>
> In fact, empirically I've seen that __FILE__ is expanded to whatever
> path gets passed to the compiler.
> You can easily see how stuff build with cmake get a full path in there,
> whereas stuff built with make gets a path relative to the Makefile.
Mattias has just showed me that in fact __FILE__ is too malleable:
mattia@warren /tmp/tmp % cat test.c
#include <stdio.h>
int main() {
printf("%s\n", __FILE__);
}
mattia@warren /tmp/tmp % gcc test.c ; ./a.out
test.c
mattia@warren /tmp/tmp % gcc ./test.c ; ./a.out
./test.c
mattia@warren /tmp/tmp % gcc /tmp/tmp/./test.c ; ./a.out
/tmp/tmp/./test.c
So yes, the cornerstone of my assumption was totally wrong. My
apologies for all the noise, all I can say is: today I learned
something new.
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
--- End Message ---
