Hi Everyone,
An FYI since I saw some chatter about Noreturn recently...
I'm building GnuTLS 3.6.12 release tarball on OS X 10.9. GnuTLS has a
copy of gnulib. The compile is failing:
gcc -DHAVE_CONFIG_H -I. -I.. -I./gl -I./gl -I./../lib/includes
-I./../lib/includes -I./../libdane/includes -I./..
Giulio Benetti wrote:
> > Ah! Most of the contents of this is OK. But
> >- gettext_noop
> >- gettext_printf
> > don't belong there.
>
> I see that usually glibc #define gettext_noop() in regex_internal.h that
> in order #include libintl.h[1] so, the same usage as gnulib does.
The big di
Hi Bruno,
On 1/27/20 8:29 PM, Bruno Haible wrote:
Giulio Benetti wrote:
There should not be a in public include file directories!
Indeed there is not, there is and it is part of uclibc:
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/include/libintl.h
Ah! Most of the contents of th
The container types (modules list, set, oset, map, omap) can be used in C++,
with casts. It is customary in C++ to use template classes in order to
avoid casts in user code. I'm doing this here:
Data type C++ class Module Include file
Sequential list gl_List list-c++ "g
Compiling a C++ file that includes xalloc.h, I get an error on FreeBSD 12:
In file included from ../../gltests/test-list-c++.cc:20:
In file included from ../../gltests/../gllib/gl_list.hh:22:
In file included from ../../gltests/../gllib/gl_xlist.h:22:
../../gltests/../gllib/xalloc.h:51:8: error: a
Hi Jim,
> Perhaps it's because I have been writing deliberately imperative and
> active-voice comments for so long that I find no ambiguity there.
Yes, 13 years ago, apparently I used this style as well. Nowadays I'm
used to the descriptive style, because it is more established. [1]
> I have mad
> +2020-02-02 Pádraig Brady
> +
> + read-file: reduce max size from SIZE_MAX to PTRDIFF_MAX
Looks good as well.
Bruno
Pádraig Brady wrote:
> +2020-02-02 Pádraig Brady
> +
> + sysctl.h: avoid including on glibc
> + * lib/nproc.c: Avoid including deprecated and unneeded header on GLIBC.
> + * lib/physmem.c: Likewise.
Looks good. The sysctl() invocations below are not enabled on glibc systems,
because
On Sun, Feb 2, 2020 at 4:17 AM Bruno Haible wrote:
> Each time I read the function specifications in gl_list.h, the use of
> imperative voice ("Return true if ...") feels wrong. "Returns true if ..." is
> the correct grammar.
>
> Why? Because imperative form is used to instruct someone. In the con
On x86_64 with glibc-2.30, gcc 9.2 is giving:
error: argument 2 value '18446744073709551615'
exceeds maximum object size 9223372036854775807
[-Werror=alloc-size-larger-than=]
The details of this restriction are discussed at:
https://stackoverflow.com/q/42574890/4421
* lib/read-file.c: s/SIZE_
* lib/nproc.c: Avoid including deprecated and unneeded header on GLIBC.
* lib/physmem.c: Likewise.
---
ChangeLog | 6 ++
lib/nproc.c | 2 +-
lib/physmem.c | 2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 55cd67f6f..1e5f94d3c 100644
--- a/
Each time I read the function specifications in gl_list.h, the use of
imperative voice ("Return true if ...") feels wrong. "Returns true if ..." is
the correct grammar.
Why? Because imperative form is used to instruct someone. In the context
of the documentation of a function, there are two "who"s
12 matches
Mail list logo
