Tim Rühsen wrote:
> thanks, with this patch the build completes !
ok, I pushed the fix:
2018-02-04 Bruno Haible
signal-h, monetary, strings: Fix build failure in some cases.
Reported by Tim Rühsen .
* modules/signal-h (Makefile.am): In the GNULIB_* substitutions, use
Hi Jim,
> I wanted to update sed to latest gnulib, but found that the new
> nl_langinfo tests would fail on fedora 27 with glibc-2.26, where
> nl_langinfo (ALTMON_1) returns the empty string:
>
> FAIL: test-nl_langinfo.sh
> =
>
> test-nl_langinfo.c:95: assertion 'strlen (
Hi all,
If you are familiar with Travis CI or Appveyor CI, please help keeping gnulib
at a high quality!
It is normal for a developer to push a buggy commit by mistake. But it should
not be normal that such a mistake, that leads to a test failure on standard
glibc systems, remains unnoticed for 1
Am Sonntag, den 04.02.2018, 11:20 +0100 schrieb Bruno Haible:
> Hi all,
>
> If you are familiar with Travis CI or Appveyor CI, please help
> keeping gnulib
> at a high quality!
>
> It is normal for a developer to push a buggy commit by mistake. But
> it should
> not be normal that such a mistake,
On Sun, Feb 4, 2018 at 11:04 PM, Bruno Haible wrote:
> Hi Jim,
>
>> I wanted to update sed to latest gnulib, but found that the new
>> nl_langinfo tests would fail on fedora 27 with glibc-2.26, where
>> nl_langinfo (ALTMON_1) returns the empty string:
>>
>> FAIL: test-nl_langinfo.sh
>> ===
Hi Tim,
> I have CI experience with several projects and I am willing to help.
Cool!
> From my experience and knowledge, the Gitlab CI is much more
> configurable than e.g. Travis. It is docker based and thus limited to
> all kinds of Linux variants (including cross-platform builds, e.g.
> MinGW
Am Sonntag, den 04.02.2018, 13:29 +0100 schrieb Bruno Haible:
> Hi Tim,
>
> > I have CI experience with several projects and I am willing to
> > help.
>
> Cool!
>
> > From my experience and knowledge, the Gitlab CI is much more
> > configurable than e.g. Travis. It is docker based and thus limit
Bruno Haible wrote:
Hi Paul,
By the way, why write "if __GNUC__ >= 5 && !defined __cplusplus &&
!defined __clang__" instead of "ifdef __CHKP__"? The latter is easier to
read
I couldn't find any documentation for this __CHKP__ macro.
It's not documented in the GCC manual. I found documen
Florian Weimer wrote:
-fcheck-pointer-bounds in GCC doesn't really work.
I agree that -fcheck-pointer-bounds is not suitable for production code.
However, I am not as skeptical about its utility. I found a real bug in GNU
Emacs with it, a bug that was not found with other checkers. So I view
Bruno Haible wrote:
Paul Eggert wrote:
converting a pointer to uintptr_t and back means that GCC won't connect
the resulting pointer to the original and this messes up bounds checking
on the result.
I don't observe this. This test program:
The problem typically doesn't occur with simple casts
Hi Paul,
> I view conversion from intptr_t to pointer as being in a
> similar category: if we avoid these conversions now we will be saving some
> work
> in the future.
If you can't cast from 'void *' to 'uintptr_t' and back, the language is no
longer C any more. Indeed, with the added __bnd_*
Bruno Haible wrote:
If you can't cast from 'void *' to 'uintptr_t' and back, the language is no
longer C any more.
Not really. C has been like that ever since uintptr_t was introduced back in
C99, as uintptr_t has always been optional. Even when uintptr_t is present I
doubt whether gcc -fchec
12 matches
Mail list logo
