Collin Funk wrote:
> Does glibc take bug reports for that or is it waiting for the
> specification to be official (i.e. not a draft)?
glibc often implements new functionalities from the standards ahead
of time. (Look at Joseph Myers' commits in glibc.) The reasoning is
the same as the one I gave i
On 5/12/24 1:30 PM, Paul Eggert wrote:
> I sense a bit of confusion here. Although POSIX allows symbols
> like be16toh to be macros, I don't see where it allows be16toh(X) to evaluate
> X more than once, so an expression like be16toh(i++) has well-defined
> behavior even though it has a side ef
On 2024-05-12 12:50, Bruno Haible wrote:
Your real goal, which is — AFAIU — to allow distros to discard part
or all of the tarball and to redo the packaging work done by the release
manager in a different way, would be better served with a
1) machine-readable file,
2) somewhere in or in th
On 2024-05-12 12:47, Collin Funk wrote:
Yeah, I read the POSIX draft and it says that they may be macros. I
doubt the byteswap.h and endian.h functions are used with non-constant
expression arguments that often.
I sense a bit of confusion here. Although POSIX allows
symbols like be16toh to be
On 5/12/24 1:02 PM, Bruno Haible wrote:
> The simple fix to your worry is: Let the user use '-Wall' routinely.
> gcc has a warning option '-Wsequence-point', included in '-Wall'.
> clang has a warning option '-Wunsequenced', included in '-Wall'.
> The do the job, and I have not seen them produce fa
Collin Funk wrote:
> I worry though that in some cases programs will be accustomed to
> glibc's behavior. Since all of the functions are just macros to static
> inline functions in arguments will only be evaluated
> once. It seems like it could be the cause of some unexpected bugs...
The simple f
Hi Simon,
> including the commit hash provide some additional information that may
> be useful further down the line
That is a bit weak as a rationale. There are many additional informations
that "may be useful" to include. Isn't this move part of a bigger plan of
yours, which is to decompose rel
On Sun, May 12, 2024 at 3:23 PM Collin Funk wrote:
> A few months ago there was a suggestion on emacs-devel to use
> __builtin_bswap functions when available [1]. While I agree that GCC
> can deal with the optimizations properly, I noted an important
> difference between the macros in byteswap.h.
On 5/12/24 12:38 PM, Paul Eggert wrote:
>> Also if we can agree upon making sure these are defined as functions,
>> what is the proper way to test it in a configure script? My instinct
>> tells me that assigning a function pointer to bswap_16, etc. would
>> fail if they are macros
>
> I don't see
On 2024-05-12 12:23, Collin Funk wrote:
I think the best decision is to use
'extern inline' to match the behavior of glibc.
Yes, with the usual _GL_EXTERN business.
Also if we can agree upon making sure these are defined as functions,
what is the proper way to test it in a configure script?
On 2024-05-12 11:43, Collin Funk wrote:
I have similar feelings about some stuff in gnulib-tool.py. We have
lines like this:
#
# Define GLImport class
#
class GLImport:
+1 on that. It's too close to the classic:
i = i + 1; /* Add 1 to i. *
A few months ago there was a suggestion on emacs-devel to use
__builtin_bswap functions when available [1]. While I agree that GCC
can deal with the optimizations properly, I noted an important
difference between the macros in byteswap.h.in and inline functions
provided by glibc.
Using this test p
Hi Bruno,
On 5/12/24 7:09 AM, Bruno Haible wrote:
> Now that we have unit tests for the backtrace* functions, let's see what
> they produce:
Nice work!
> Collin, feel free to report the FreeBSD, NetBSD, OpenBSD bugs if you have
> time for that. It's only by reporting bugs that we can trigger tha
On 5/12/24 8:23 AM, Paul Eggert wrote:
> Is this stuff documented somewhere in the .texi files? If not, I suppose it
> should be.
I'm not sure. The only reason I noticed was because I was working on
endian.h and using stdbit as a template since my m4 talents are lacking...
> Frankly I continue t
On 2024-05-12 09:27, Jim Meyering wrote:
I like it. Wording and placement are spot on.
Looks good to me too.
I at first thought to suggest adding announce-gen's own version number
to the announcement (to help people who want to check the announcement
itself), but there's no need as it's deri
I like it. Wording and placement are spot on.
Thanks.
On Sun, May 12, 2024, 08:42 Simon Josefsson via Gnulib discussion list <
bug-gnulib@gnu.org> wrote:
> All,
>
> Our release announcements does not mention the git commit hash that was
> used to prepare the release. While SHA1 is broken, I sti
All,
Our release announcements does not mention the git commit hash that was
used to prepare the release. While SHA1 is broken, I still think
including the commit hash provide some additional information that may
be useful further down the line, and hopefully including doesn't incur
too much cogn
On 2024-05-11 23:48, Collin Funk wrote:
+# stddef_h.m4
+# serial 1
I see that you use my method of making sure files have license
headers, just copying another file. :)
Thanks, I fixed that.
Is this stuff documented somewhere in the .texi files? If not, I suppose
it should be.
Frankly I co
On running 'make release' I got this error message:
GEN release-prep
fatal: No names found, cannot describe anything.
make[1]: Entering directory '/home/jas/src/inetutils'
The error message is harmless since the code already handled this
situation, but the error message should be silenced
Now that we have unit tests for the backtrace* functions, let's see what
they produce:
* I see a test failure on FreeBSD 12.0/i386: The returned size is not in range,
it is (size_t)(-1).
The test passes on FreeBSD 14.0/i386.
In the FreeBSD git history, I can see that the bug fix was in commi
Hi Collin,
> The reasoning for printing the backtrace was so that the output can be
> compared with the BSD implementation or various linker flags, etc.
> Seemed like it might be helpful.
Yes, of course it is helpful. Some functions have a specification that
leaves a lot of room to the implementa
On 5/12/24 4:39 AM, Collin Funk wrote:
> I left backtrace_symbols_fd untested because I did not see too much
> benefit in testing it. Its job is similar enough to backtrace_symbols
> but would require thinking about module dependencies and headers for
> create () and unlink (), or similar.
I forgo
Hi Bruno,
On 5/12/24 3:43 AM, Bruno Haible wrote:
> Reading through your test, I notice that when size == 0 && symbols != NULL,
> the symbols pointer is not freed. So I went to look deeper.
>
> Reading through the documentation at
> https://www.gnu.org/software/libc/manual/html_node/Backtraces.ht
Hi Collin,
> I've pushed a basic test for execinfo. Since BSD needs to link to
> -lexecinfo unlike glibc. Should catch any bugs that occur there or if
> another system adds it as a library.
Thanks.
Reading through your test, I notice that when size == 0 && symbols != NULL,
the symbols pointer is
Collin Funk wrote:
> I've applied the attached patch to fix this crash.
Thanks. Looks good.
> I'm not sure why gnulib-tool.sh handles the tabs correctly to be
> honest...
It's because after
deps=`func_get_dependencies $module | sed -e
"$sed_dependencies_without_conditions"`
the variable deps
25 matches
Mail list logo
