Eli Zaretskii wrote:
I needed this commit to prevent temacs from crashing during dumping.
Don't ask me how including errno.h (both the one from Gnulib and the
MinGW one) could cause this, especially as the preprocessed __fpending
doesn't seem to change a bit as result of that, and it doesn't see
Clément Pit–Claudel wrote:
the last check (len < length1) was added to "avoid overflow in computing sum of
lengths". But I thought int overflow was undefined behaviour, so why does the len <
length1 check make sense?
You're right, it doesn't. I fixed this by installing the attached patch into
Looks good to me.
Ordinarily I would just install innocuous changes like that...
Eli Zaretskii wrote:
> > I needed this commit to prevent temacs from crashing during dumping.
> > Don't ask me how including errno.h (both the one from Gnulib and the
> > MinGW one) could cause this, especially as the preprocessed __fpending
> > doesn't seem to change a bit as result of that, and i
On 12/15/2016 12:11 PM, Gisle Vanem wrote:
> I get errors from MSVC in i C++ mode. E.g. in compiling
> test-netdb-c++.cc:
>
> netdb.h(189): error C2440: 'return': cannot convert
> from 'INT (__stdcall *)(PCSTR,PCSTR,const ADDRINFOA *,PADDRINFOA *)' to
> 'gnulib_::_gl_getaddrinfo_wrapper::ty
Paul Eggert wrote:
> Looks good to me.
OK, pushed.
> Ordinarily I would just install innocuous changes like that...
Well, I learned to believe in code review. And especially when I feel too
self-confident, I make the biggest blunders.
Bruno
On 12/15/2016 01:13 PM, Gisle Vanem wrote:
>> I've not checked all test-*.cc files for such errors.
>
> Another issue with sys_select.in.h:
> test-sys_select-c++.cc
> sys/select.h(305): error C2440: 'return': cannot convert from
> 'int (__cdecl *)(int,fd_set *,fd_set *,fd_set *,timeval *)' t
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, Paul Eggert , emacs-de...@gnu.org
> Date: Fri, 16 Dec 2016 19:11:31 +0100
>
> On mingw, the fpending.o generated by this code, with or without this
> #include , is identical (even with debugging information [-g]).
Yes, I said that much. Which is wh
Daniel Richard G. wrote:
This recent change to fnmatch.c breaks the build on z/OS:
DEPDIR=.deps depmode=aix /bin/sh /u/darkstar/testdir/build-aux/depcomp \
xlc-wrap -DHAVE_CONFIG_H -I. -I/u/darkstar/testdir/gllib -I..
-DGNULIB_STRICT_CHECKING=1 -D_XOPEN_SOURCE=600 -DNSIG=39 -qhaltonmsg=CCN329
Eli Zaretskii wrote:
> > - How often have you tried to temacs+dump with and without the change?
> > Once each? Twice each? 10 times each? If it's a small number, you may
> > be seeing a random result and not realize it was random.
>
> I did it in two separate branches, 3 times in each one. Th
Hi Paul,
> I installed the attached to gnulib; please give it a try.
Is it intentional that regex-internal.h now uses __builtin_expect
unconditionally, yet the module 'regex' does not depend on 'builtin-expect'?
Bruno
On Fri, 2016 Dec 16 14:58-0800, Paul Eggert wrote:
>
> No, it's a compiler builtin. I installed the attached to gnulib;
> please give it a try.
Alas, git master 005973d6 gives me a new build failure:
source='/u/darkstar/testdir/gllib/allocator.c' object='allocator.o' libtool=no \
DEPDIR=.deps de
Bruno Haible wrote:
gnulib has a way to keep in your project changes relative to gnulib
that should not be pushed upstream
I'd rather not do that, as the Emacs build procedure is already too complicated.
Bruno Haible wrote:
Is it intentional that regex-internal.h now uses __builtin_expect
unconditionally, yet the module 'regex' does not depend on 'builtin-expect'?
No, and thanks for catching that typo. I installed the attached.
>From 56687b30218a291dbb8e3d7eb712183e7ed09f43 Mon Sep 17 00:00:00
I hadn't thought about the possibility that the standard includes define
__builtin_expect as a macro. I installed the attached; please give it a try.
From 50ba47004ee83c3a68d4416b8664117dc5e77eee Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 16 Dec 2016 16:47:26 -0800
Subject: [PATCH] bui
Paul Eggert wrote in ChangeLog entry:
> Is Plan 9 still a valid porting target, anyway?
Well, it got requested in 2012 [1]. And, I guess, it has some educational value
regarding Unix and minimalism.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2012-02/msg4.html
On Fri, 2016 Dec 16 16:55-0800, Paul Eggert wrote:
> I hadn't thought about the possibility that the standard includes
> define __builtin_expect as a macro. I installed the attached; please
> give it a try.
In git master d1469b79, the configure-time detection now works, but the
build fails later a
Daniel Richard G. wrote:
As an aside: It's not that the headers #define __builtin_expect as a
macro on this platform, but rather (from builtins.h):
Thanks. We should address this underyling problem. I installed the attached to
try to work around the problem. I don't want to have to modify lot
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Sat, 17 Dec 2016 00:17:31 +0100
>
> Since, as you say, the crash occurs during dumping, this is what I would
> turn to now. Do you have a systematic approach for debugging crashes during
> dump? If dump is based on malloc, does it help to set
19 matches
Mail list logo
