Hi all,
Bison started to use the new attribute module, but it generates conflicts with
other modules, because one definition comes from config.h, and another from the
other module's file. For instance:
> In file included from ../lib/bitsetv.c:21:
> In file included from ../lib/bitsetv.h:24:
>
On a recent Haiku/x86_64, a gnulib testdir fails to compile:
In file included from ../../gltests/test-uchar.c:23:
../../gltests/../gllib/verify.h:216:41: error: static assertion failed: "verify
((char16_t)(-1) >= 0)"
# define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
Hi Akim,
> Bison started to use the new attribute module, but it generates conflicts
> with other modules, because one definition comes from config.h, and another
> from the other module's file. For instance:
>
> > In file included from ../lib/bitsetv.c:21:
> > In file included from ../lib/bit
I wrote:
> - In the lib/*.in.h header files, that may (in some circumstances) be used
> without a preceding '#include ' and that therefore are
> designed
> to be as standalone as possible, you can use the _GL_ATTRIBUTE_* macros
> if you have added a fallback definition.
The
Please add
#ifdef DEBUG
# include
#endif
at the beginning of c-stack.c.
When the DEBUG flag is enabled, c-stack.c uses sprintf and without the
suggested addition gcc complains about an implicit declaration of the
function sprintf.
Thanks,
Marc
Hi Akim,
> > In file included from ../lib/bitsetv.c:21:
> > In file included from ../lib/bitsetv.h:24:
> > In file included from ../lib/bitset.h:31:
> > In file included from ../lib/bitset/base.h:28:
> > ../lib/xalloc.h:43:10: warning: '_GL_ATTRIBUTE_ALLOC_SIZE' macro redefined
> > [-Wmacro-redef
Hi Marc,
> Please add
>
> #ifdef DEBUG
> # include
> #endif
>
> at the beginning of c-stack.c.
>
> When the DEBUG flag is enabled, c-stack.c uses sprintf and without the
> suggested addition gcc complains about an implicit declaration of the
> function sprintf.
Yup. Thanks for the suggestion.
Hi Bruno,
> Le 9 mai 2020 à 12:37, Bruno Haible a écrit :
>
> Hi Akim,
>
> Also, I avoid to use _GL_ATTRIBUTE_FORMAT and ATTRIBUTE_FORMAT, because of a
> tricky override of 'printf' by '__printf__', done in gnulib and libintl.
Then, shouldn't gnulib expose the _GL_ATTRIBUTE_FORMAT_(PRINTF|SCAN
> Le 9 mai 2020 à 13:24, Bruno Haible a écrit :
>
> Hi Akim,
>
>>> In file included from ../lib/bitsetv.c:21:
>>> In file included from ../lib/bitsetv.h:24:
>>> In file included from ../lib/bitset.h:31:
>>> In file included from ../lib/bitset/base.h:28:
>>> ../lib/xalloc.h:43:10: warning: '_GL
Actually, given the number of times this pattern is used, I would personally
introduce gl_SUBSTS, a variadic version of AC_SUBST, to avoid all this
repetition, say something like
gl_SUBSTS(
[[GNULIB_ISWBLANK], [0]],
[[GNULIB_ISWDIGIT], [0]],
[[GNULIB_ISWXDIGIT], [0]],
[[GNULIB_
Hi Akim,
> So there remains this one. Ok to install?
Yes. Looks good.
Bruno
Hi Akim,
> AC_SUBST([GNULIB_ISWBLANK], [0])
> AC_SUBST([GNULIB_ISWDIGIT], [0])
> AC_SUBST([GNULIB_ISWXDIGIT], [0])
> AC_SUBST([GNULIB_WCTYPE], [0])
> AC_SUBST([GNULIB_ISWCTYPE], [0])
> AC_SUBST([GNULIB_WCTRANS], [0])
> AC_SUBST([GNULIB_TOWCTRANS], [0])
No, no, noo!! This would m
Hi Paul,
I can't really comfortably use a set of macro, for which I need to look
up a C in-progress standard, a C++ standard, and the GCC documentation.
So, I've added documentation, that answers the questions:
- Where should the attribute be placed?
- On which entities is it supported?
- W
Hi Bruno,
> Le 9 mai 2020 à 17:25, Bruno Haible a écrit :
>
> Hi Akim,
>
>> AC_SUBST([GNULIB_ISWBLANK], [0])
>> AC_SUBST([GNULIB_ISWDIGIT], [0])
>> AC_SUBST([GNULIB_ISWXDIGIT], [0])
>> AC_SUBST([GNULIB_WCTYPE], [0])
>> AC_SUBST([GNULIB_ISWCTYPE], [0])
>> AC_SUBST([GNULIB_WCTRANS], [0])
>>
On 5/9/20 8:46 AM, Bruno Haible wrote:
> The text I wrote is meant be easier to understand upon first use, but
> still as correct (or nearly as correct) as the corresponding GCC
> documentation.
Thanks, that's a good idea and makes attribute.h easier to use. I went through
the comments and tweak
Hi Akim,
(A) > I'm looking for means to avoid repetitions, and boilerplate.
It needs to be balanced against the other characteristics of maintainability.
Two important aspects are:
(B) Making the code easy to understand.
(C) Making it easy to find all definitions and all references of an
ide
Hi all, volunteers,
GCC 10 has a new static analysis pass [1][2]. I compiled a gnulib testdir with
CC="gcc -fanalyze". Find attached the part of the log that compiles the gllib/
directory. (The log of the gltests/ directory is uninteresting: here gcc reports
mostly cases where memory was allocated
The first bug in that output:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
lib/careadlinkat.c:73:8: note: declared here
73 | char stack_buf[1024];
|^
This is a false alarm. I installed the attached patch to pacify GCC (if you
build
18 matches
Mail list logo
