Re: [bug #60798] Make does not compile with GCC 11.1.0
On Sat, Jun 19, 2021 at 11:10:14AM -0400, Dmitry Goncharov wrote:
> On Sat, Jun 19, 2021 at 10:31 AM Dmitrii Pasechnik
> wrote:
> > It's undefined behaviour in C to point to such a location, isn't it?
> > Is this hack really needed?
>
> There is no hack. It is pointer arithmetic in c. p[-1] is the same as *(p-1).
Compiler does not guarantee you that doing something with p[-1]
is not going to end in a segfault. It's hack, as it just happens to work, but
YMMV.
E.g. clang 10, or Apple's clang 12, will print a warning:
warning: array index -1 is before the beginning of the array [-Warray-bounds]
printf("%d", p[-1]);
^ ~~
Re: [bug #60798] Make does not compile with GCC 11.1.0
On Sat, Jun 19, 2021 at 10:52:41AM -0400, Paul Smith wrote: > On Sat, 2021-06-19 at 15:31 +0100, Dmitrii Pasechnik wrote: > > On Fri, Jun 18, 2021 at 12:53:32PM -0400, Paul D. Smith wrote: > > > > > Follow-up Comment #1, bug #60798 (project make): > > > FWIW, this warning is not valid in this situation. The code is > > > correct; p will always be pointing into a valid buffer and never > > > pointing at the first character in that buffer, so p[-1] always > > > points to valid memory. > > > > It's undefined behaviour in C to point to such a location, isn't it? > > To point to which such location? As I said, we know for a fact that p > does not point at the first character of the array. It's clearly legal > in C to walk backwards through an array!! And referencing the previous > element in an array is certainly not a hack. > > I don't think I understand. p[] occupies a continuous memory area, starting from p[0], but p[-1] is not guaranteed by the standard to be accessible for you (well, unless you control the memory layout by placing p in a struct, not as the 1st member, but then why would you need p[-1] in the 1st place?) What's unclear about it?
Re: [bug #60798] Make does not compile with GCC 11.1.0
On Fri, Jun 18, 2021 at 12:53:32PM -0400, Paul D. Smith wrote: > Follow-up Comment #1, bug #60798 (project make): > > FWIW, this warning is not valid in this situation. The code is correct; p > will always be pointing into a valid buffer and never pointing at the first > character in that buffer, so p[-1] always points to valid memory. It's undefined behaviour in C to point to such a location, isn't it? Is this hack really needed? > > When building code for production use, you should never use -Werror.
Re: Idea: Automatically correct timestamps
On Sun, Jun 09, 2019 at 10:11:32PM -0400, Paul Smith wrote: > On Sun, 2019-06-09 at 18:24 -0400, David A. Wheeler wrote: > > Proposed solution: > > By default, make should check the timestamp of the non-.PHONY target(s) > > produced after > > executing a rule, and ensure that their timestamps are at least equal to the > > timestamps to the files that caused execution of the rule in the first place > > (if the target is created at all). > > I don't think this can work, as-is. > > It's a common paradigm in make (including POSIX make) where there is a > rule that could cause a very expensive operation to be started, to > instead make a cheap test and if it determines the expensive operation > is not needed it will not update the target at all. > > You will have to continue to run that cheap test every time, until you > finally allow the target to be rebuilt, but it can still save a lot of > work. > > Even automake uses a "move_if_changed" type of thing, to avoid re- > running configure when it's not necessary. > > This problem could be addressed by adding a clause that if the > timestamp of the target was not modified at all, it should be left > alone. It's hard to come up with a justifiable purpose for a target's > mod time to be changed, but to something less than one of its > prerequisites. > > Although doubtless someone has done it, on purpose, somewhere for some > reason. > > > In many cases I suspect this would eliminate calls for using md5 > > hashes and special state; I suspect many of those requests are really > > trying to deal with problems of clock slew that this proposal > > resolves. > > Hm. Maybe people have just given up reporting this problem but > honestly I can't remember the last time I had anyone ask questions here > or on StackOverflow that are related to clock skew. I sort of thought > it was a solved problem. No, it's definitely not the case. Probably it gets less frequently reported as disks get cheaper, and multi-user systems less used for development than in the olden days. Building big projects on an NFS, be it a "classcal" NFS or a supposedly high-performant solution from a commercial vendor (IBM makes something like this), as people tend to do nowadays on HPC systems, is still problematic. In particular large projects using autotools are affected, for they have particular ways of doing things that were appropriate 20-30 years ago, but not nowadays. A typical error message from configure would say: checking whether build environment is sane... configure: error: newly created file is older than distributed files! Check your system clock We recommend doing builds on a local disk instead, but it's not always feasible for one or another reason. HTH Dima > > Most of the requests I see these days that would require a "last state > database" wouldn't be helped by md5 checks: mainly they're asking for > things like rebuilding targets automatically when compiler options have > changed etc. Things like that can be done today with a lot of fancy > trickery but people would rather it "just worked". > > > ___ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system
On Mon, Apr 02, 2018 at 10:44:53AM -0400, Dennis Clarke wrote: > On 02/04/18 10:21 AM, Dmitrii Pasechnik wrote: > > I just wonder whether this is a relatively common case of an updated > > make dependence, which is incompatible on the binary level (e.g. due to > > wrong minor version number). > > E.g. if your make has guile extension enabled, it is easy to shoot > > yourself in the foot by hacking on one of libguile dependencies... > > > > you went offlist .. let's not. OK, I just was on a phone client that does not know my "real" email address, used by the list, sorry. > > Also, not sure how to check for whatever it is you suggest. > > root@phobos:~# which make > /usr/bin/make > root@phobos:~# file /usr/bin/make > /usr/bin/make: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), > dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, > BuildID[sha1]=fcdb8756a78eb97afc306cc2c6acce391bfafbc3, stripped > root@phobos:~# I meant to suggest to have a look at the output of ldd, to see if there is anything weird there. E.g. I have (on the latest Fedora): $ ldd `which make` /usr/bin/make: linux-vdso.so.1 (0x7fff2dcbc000) libguile-2.0.so.22 => /lib64/libguile-2.0.so.22 (0x7f7cc7d0) libgc.so.1 => /lib64/libgc.so.1 (0x7f7cc79a4000) libdl.so.2 => /lib64/libdl.so.2 (0x7f7cc77a) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7cc7581000) libc.so.6 => /lib64/libc.so.6 (0x7f7cc71ac000) libffi.so.6 => /lib64/libffi.so.6 (0x7f7cc6fa4000) libunistring.so.2 => /lib64/libunistring.so.2 (0x7f7cc6c32000) libgmp.so.10 => /lib64/libgmp.so.10 (0x7f7cc69bb000) libltdl.so.7 => /lib64/libltdl.so.7 (0x7f7cc67b1000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f7cc657b000) libm.so.6 => /lib64/libm.so.6 (0x7f7cc6265000) /lib64/ld-linux-x86-64.so.2 (0x7f7cc82c8000) libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x7f7cc6062000) libfreebl3.so => /lib64/libfreebl3.so (0x7f7cc5e5f000) Best, Dima > > Dennis > > > ___ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
