I did:
> 2024-07-17 Bruno Haible
>
> stack-trace: Use libasan as an alternative to libbacktrace.
> * m4/stack-trace.m4 (gl_STACK_TRACE_EARLY): As a second choice, use
> libasan.
However, on NetBSD 10.0, every program that links with libasan exits
without even reaching main().
Yesterday I renamed _gl_pre_abort() to print_stack_trace(). But the latter
is a symbol that could collide with some symbol defined by the application,
and should therefore not be defined by gnulib's override
unconditionally. This patch fixes that.
2024-07-18 Bruno Haible
stdlib: Don'
The stack-trace and abort-debug modules are now in a state where they
can be documented. Done as follows:
2024-07-18 Bruno Haible
doc: Document the stack-trace and abort-debug modules.
* doc/stack-trace.texi: New file.
* doc/gnulib.texi (Particular Modules): Include it
On 2024-07-18 05:25, Bruno Haible wrote:
The stack-trace and abort-debug modules are now in a state where they
can be documented. Done as follows:
Thanks. Are these modules safe to use in signal handlers? I suspect that
Emacs would need that, in order to use them. Either way, it should be
doc
On 2024-07-18 04:21, Bruno Haible wrote:
on NetBSD 10.0, every program that links with libasan exits
without even reaching main(). It merely prints
"This sanitizer is not compatible with enabled ASLR"
to standard error and exits with status 0 (yes, 0 !!!).
If I understand things correctly a sim
If xstrtol() was being called with a base of 1, under some conditions it
would invoke Undefined Behavior.
Here's the code that would trigger UB:
char *end;
xstrtol(str, &end, 1, ...); // Let's ignore trailing args.
The reason why this triggers UB is that since the following li
Alejandro Colomar wrote:
> If xstrtol() was being called with a base of 1, under some conditions it
> would invoke Undefined Behavior.
Yes, sure. A numeric base of 1 makes no sense, mathematically.
Thanks for the patch; applied.
Note that I disagree with the statement from
https://github.com/voi
Paul Eggert wrote:
> If I understand things correctly a similar problem was also on FreeBSD
> with PIE and the bug wasn't fixed until November of last year:
>
> https://github.com/llvm/llvm-project/commit/7440e4ed85aa992718d4b5ccd1c97724bc3bdd2c
This issue does not affect the Gnulib 'stack-trace
Hi Bruno,
On Thu, Jul 18, 2024 at 08:06:07PM GMT, Bruno Haible wrote:
> Alejandro Colomar wrote:
> > If xstrtol() was being called with a base of 1, under some conditions it
> > would invoke Undefined Behavior.
>
> Yes, sure. A numeric base of 1 makes no sense, mathematically.
>
> Thanks for the
Paul Eggert wrote:
> If I understand things correctly a similar problem was also on FreeBSD
> with PIE and the bug wasn't fixed until November of last year:
>
> https://github.com/llvm/llvm-project/commit/7440e4ed85aa992718d4b5ccd1c97724bc3bdd2c
Btw, I don't know why they do this. For the purpos
strtol(3) has a limited set of possible states:
- The base was invalid.
- return 0
- errno = EINVAL
- endp is not set
We cover this case with the assure() call, before strtol(3).
- No conversion was performed.
- return 0
- errno may be EINVAL, or may be unset.
- *endp
Paul Eggert wrote:
> > The stack-trace and abort-debug modules are now in a state where they
> > can be documented. Done as follows:
>
> Thanks. Are these modules safe to use in signal handlers?
No, they aren't.
Find attached the log of 'ltrace gltestst/test-stack-trace'. While
libbacktrace care
Reading the man page of abort(), I see that it deals with situations
where SIGABRT is masked (via sigprocmask) or has a handler installed.
The override needs to have the same behaviour.
2024-07-18 Bruno Haible
abort-debug: Don't assume that signal SIGABRT is unmasked and unhandled.
Hi Alejandro,
> strtol(3) has a limited set of possible states:
> ...
> The condition '*endp != s && errno != 0 && errno != ERANGE' is
> unreachable. The only errno possible if '*endp != s' is ERANGE.
Such a statement can be true if you look at the standards (ISO C, POSIX).
However, there's a d
On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote:
> Hi Alejandro,
Hi Bruno,
> > strtol(3) has a limited set of possible states:
> > ...
> > The condition '*endp != s && errno != 0 && errno != ERANGE' is
> > unreachable. The only errno possible if '*endp != s' is ERANGE.
>
> Such a sta
[CC -= Andrew, per explicit request]
On Thu, Jul 18, 2024 at 11:25:11PM GMT, Alejandro Colomar wrote:
> On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote:
> > Hi Alejandro,
Hi Bruno,
> > > strtol(3) has a limited set of possible states:
> > > ...
> > > The condition '*endp != s && errno
Alejandro Colomar wrote:
> > - Some systems return "wrong" errno values. Example: [1]
> > - Some systems fail with ENOMEM when memory is tight. Who says that
> > an implementation of strtol() cannot use malloc() ? Some implementations
> > of strtod() do use malloc().
> >
> > So, what y
Hi Bruno,
On Fri, Jul 19, 2024 at 12:34:39AM GMT, Bruno Haible wrote:
> Alejandro Colomar wrote:
> > > - Some systems return "wrong" errno values. Example: [1]
> > > - Some systems fail with ENOMEM when memory is tight. Who says that
> > > an implementation of strtol() cannot use malloc()
On Fri, Jul 19, 2024 at 12:14:19AM GMT, Alejandro Colomar wrote:
> [CC -= Andrew, per explicit request]
>
> On Thu, Jul 18, 2024 at 11:25:11PM GMT, Alejandro Colomar wrote:
> > On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote:
> > > Hi Alejandro,
>
> Hi Bruno,
>
> > > > strtol(3) has a
Stop tagging me in your submissions. I have no involvement in any of this
activity.
--
Andrew J. Hesford
a...@sideband.org
[Mobile communication]
> On Jul 18, 2024, at 5:25 PM, Alejandro Colomar wrote:
>
> On Thu, Jul 18, 2024 at 11:09:40PM GMT, Bruno Haible wrote:
>> Hi Alejandro,
>
> Hi Br
On 2024-07-18 12:53, Alejandro Colomar wrote:
I think it'd be common to assume that unless specifically
documented, you behave like POSIX's strtol(3), which produces defined
behavior for a base of 1.
Fair enough. I installed the attached Gnulib patch which addresses that
point, along with the
Inspired by the discussion around xstrtol, I looked at xstrtod.
I plan to commit this documentation, when savannah allows. And to look
at the two FIXMEs regarding platform-dependent behaviour...
2024-07-18 Bruno Haible
xstrtod, xstrtold: Add documentation.
* lib/xstrtod.h (xs
22 matches
Mail list logo
