> On Jul 29, 2024, at 9:01 AM, bug-gnulib-requ...@gnu.org wrote:
>
> Message: 5
> Date: Mon, 29 Jul 2024 11:47:31 -0400
> From: Jeffrey Walton
> To: Bruno Haible
> Cc: bug-gnulib@gnu.org, Eric Blake
> Subject: Re: should asprintf and friends guarantee sane pointer on
>failure?
> Message-
A compilation error with clang++ was fixed in clang 16. See:
$ cat foo.cc
__attribute__ ((__deprecated__)) [[__nodiscard__]] int bar1 (int); // error in
clang < 16
[[__nodiscard__]] __attribute__ ((__deprecated__)) int bar2 (int);
With clang 15:
$ clang++ -S foo.cc
foo.cc:1:34: error: an attrib
Unfortunately, the use of _GL_ATTRIBUTE_NODISCARD at the beginning of a
function declaration, that I committed earlier today, produces g++ warnings.
Here is an example:
$ g++ -S -Wall foo.cc
foo.cc:3:1: warning: attributes are not permitted in this position
[-Wattributes]
3 | __attribute__((_
This patch fixes a gcc warning about an unused variable.
2024-07-29 Bruno Haible
vaszprintf-posix tests: Fix a gcc warning.
* tests/test-vaszprintf-posix.c (test_function): Remove an unused
variable.
diff --git a/tests/test-vaszprintf-posix.c b/tests/test-vaszprintf-p
A misspelling of __clang_major__ in glibc made it into Gnulib.
Paul fixed it in glibc:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7999b8a3aa76eae4f75b76fd6797e832274b8114
but the occurrences in Gnulib are still opportunities for bugs
through copy&paste.
This patch fixes them.
2024-07
When glibc has marked a function with __attribute__ ((__warn_unused_result__)),
Gnulib needs to do the same. Otherwise, in some cases, Gnulib has the effect
of turning off useful warnings.
This patch does it. (I got the list of symbols by grepping for '__wur' in
system with glibc 2.40 header files
This patch fixes a small copy&paste mistake.
2024-07-29 Bruno Haible
chdir: Fix mistake in GNULIB_POSIXCHECK.
* lib/unistd.in.h: Don't attach the chdir warning to the 'chown'
function.
diff --git a/lib/unistd.in.h b/lib/unistd.in.h
index 9ca377c4df..ae92587b6d 100644
This patch fixes a trivial oversight:
2024-07-29 Bruno Haible
atoll: Fix module dependencies.
* modules/atoll (Depends-on): Add stdlib.
diff --git a/modules/atoll b/modules/atoll
index ac5fdcb9b9..8f7c347af5 100644
--- a/modules/atoll
+++ b/modules/atoll
@@ -6,6 +6,7 @@ lib/a
Paul Eggert wrote:
> > (a) ptr is unchanged.
> > (b) ptr is set to NULL.
> > (c) ptr is set to a non-NULL pointer that is not free()able.
> > (d) ptr is set to a non-NULL pointer that is freshly allocated
> > and thus meant to be freed.
> >
> > It is quite obv
On 2024-07-29 07:35, Bruno Haible wrote:
What can happen with the result pointer ptr if
asprintf (&ptr, ...)
fails? There are four possibilities:
(a) ptr is unchanged.
(b) ptr is set to NULL.
(c) ptr is set to a non-NULL pointer that is not free()able.
(d) p
On Mon, Jul 29, 2024 at 11:37 AM Bruno Haible wrote:
>
> Jeffrey Walton wrote:
> > You should consider making the interface easy to use correctly, and
> > hard to use incorrectly. That will help novice programmers avoid
> > mistakes.
>
> Novice programmers need to learn that they need to look at t
Eric Blake wrote:
> >The only reasonable change that should be done is to mark the
> >declaration of asprintf and vasprintf with attribute
> >__warn_unused_result__. This way, the compiler will warn about
> >the crappy code.
>
> Makes sense; I would be in favor of that change in gn
Jeffrey Walton wrote:
> You should consider making the interface easy to use correctly, and
> hard to use incorrectly. That will help novice programmers avoid
> mistakes.
Novice programmers need to learn that they need to look at the return
value. Once they have learned this, everything is easy.
On Mon, Jul 29, 2024 at 10:36 AM Bruno Haible wrote:
>
> I see two — mostly unrelated — topics in your mail and the referenced
> threads.
>
> 1) The coding paradigm.
>
>30 years ago I saw a piece of code from Microsoft, which called
>fopen() and assumed that the return value was != NULL.
>
On Mon, Jul 29, 2024 at 09:58:57AM -0500, Eric Blake wrote:
> On Mon, Jul 29, 2024 at 04:35:57PM GMT, Bruno Haible wrote:
> > Hi Eric,
> >
> > I see two — mostly unrelated — topics in your mail and the referenced
> > threads.
> >
> > 1) The coding paradigm.
>
> >
> >The only reasonable chan
Eric Blake wrote:
> On the other hand, if glibc DOES decide to do (b) to match BSD, then
> why would gnulib NOT want to guarantee the same portably across all
> platforms?
Because what matters is the standards; POSIX in this case.
glibc and BSD are not the only platforms. Other platforms that hav
On Mon, Jul 29, 2024 at 04:35:57PM GMT, Bruno Haible wrote:
> Hi Eric,
>
> I see two — mostly unrelated — topics in your mail and the referenced
> threads.
>
> 1) The coding paradigm.
>
>The only reasonable change that should be done is to mark the
>declaration of asprintf and vasprintf
Hi Eric,
I see two — mostly unrelated — topics in your mail and the referenced
threads.
1) The coding paradigm.
30 years ago I saw a piece of code from Microsoft, which called
fopen() and assumed that the return value was != NULL.
Nowadays, "Solar Designer" presents us code like this:
This thread in oss-security was an interesting read:
https://www.openwall.com/lists/oss-security/2024/07/26/2
it spawned this ongoing thread in glibc:
https://inbox.sourceware.org/libc-alpha/871q3cqy0j@oldenburg.str.redhat.com/
I'm wondering if gnulib should guarantee that asprintf() and frie
Paul Eggert wrote:
> I installed the attached patch to go back to the old way of doing things,
> ...
> I didn't adjust the recently-added Gnulib test cases even though they're
> testing what is now documented to be undefined behavior, as they still
> pass on the FreeBSD and Ubuntu platforms that
glibc 2.40 adds the function families
exp10m1
exp2m1
log10p1
log2p1
logp1
All are specified by ISO C23.
This set of patches adds the logp1 family to gnulib.
2024-07-29 Bruno Haible
logp1l: Add tests.
* tests/test-logp1l.c: New file, based on tests/test-log1pl.c.
21 matches
Mail list logo
