This set of patches adds -gnu variants for the *z*printf modules
that we have so far, along with small unit tests.
2024-06-25 Bruno Haible
obstack-zprintf-gnu: Add tests.
* tests/test-obstack-zprintf-gnu.c: New file, based on
tests/test-vazsprintf-gnu.c.
* modu
Hi Dmitrii,
> Building shared libraries which depend upon
> other libraries breaks whenever a dependency found (by something like
> AC_SEARCH_LIBS) was not built with -fPIC (or whatever
> the name of this option might be on the platform in question).
> And, preferably, one might want to check that
Hi Bruno,
Bruno Haible writes:
> This set of patches adds -gnu variants for the *z*printf modules
> that we have so far, along with small unit tests.
Looks good (+ previous patches). One question though since I noticed
these functions are defined in stdio.h.
Is the correct way to use them as P
And likewise for the c-*z*printf modules:
2024-06-25 Bruno Haible
c-vazsprintf-gnu: Add tests.
* tests/test-vazsprintf-gnu.h: New file, extracted from
tests/test-vazsprintf-gnu.c.
* tests/test-vazsprintf-gnu.c: Include test-vazsprintf-gnu.h.
(test_funct
Collin Funk wrote:
> I'm not sure how portable the __asm__ redirects are.
Only supported by GCC and clang, I would say.
> could include a header with extern inline functions?
And that extern inline function would be called 'printf', right?
That would work in programs, but would be hairy in libra
To get an overview what Gnulib can do to better support the POSIX-1.2024 APIs,
I went through the POSIX.1-2024 PDF and collected references to "Issue 8"
and "Austin Group Defect".
The result are two files:
- A list of header files and functions for which the documentation might
need to chang
Bruno Haible writes:
> I plan to add these files to the maint-tools/ repository, so that we can
> track progress. For the moment, as we don't have the HTML formatted
> POSIX yet, we cannot work on the documentation part. But you can look at
> the posix-2024-impl.TODO to figure areas which you wou
Collin Funk wrote:
> Is it okay if I add inet_ntoa? It is "obsolete" in this latest revision
> but it is used everywhere including GNU Inetutils [1] [2]. FWIW I don't
> think its usage is bad as long as you don't have plans to make your
> program multithreaded.
The problems of inet_ntoa are summar
Bruno Haible writes:
> The problems of inet_ntoa are summarized in our documentation
> (doc/posix-functions/inet_ntoa.texi). The biggest problem is that
> it does not support IPv6. IPv6 is everywhere nowadays: internet
> providers give out IPv6 addresses to their customers, and probably
> 2/3 of
c-vasnprintf has a long-standing bug: When I add a unit test for it, it leads
to link errors:
/usr/bin/ld: ../gllib/libgnu.a(c-vasnprintf.o): in function `c_vasnprintf':
/GNULIB/testdir2/build-64/gllib/../../gllib/vasnprintf.c:2246: undefined
reference to `printf_parse'
/usr/bin/ld: /GNULIB/testd
Hi Collin,
> Is the correct way to use them as Paul mentioned previously?
> Like this [1]:
>
>
> #undef printf
> #define printf zprintf
This is more hairy than you might think. Because of the GCC attribute syntax.
stdio.in.h does
/* Don't break __attribute__((format(printf,M,N))). */
Bruno Haible writes:
> This is more hairy than you might think. Because of the GCC attribute syntax.
>
> stdio.in.h does
>
> /* Don't break __attribute__((format(printf,M,N))). */
> #define printf __printf__
>
> because there are not many symbols that can be used in place of 'printf'.
Ah, i
Bruno Haible writes:
> These two patches fix the bug and add the unit test. Will push once savannah
> is up again.
Seems to be up now. I think it was down since last night/early this
morning so I couldn't pull any of your previous patches either.
Collin
It has been brought to my attention that a defective memchr is
distributed with certain Android E-book readers with Android 2.3.5 that
is liable to integer overflows with large values of N:
memchr ("", 0, SIZE_MAX);
returns NULL, since:
Dump of assembler code for function memchr:
0xafd20644
Po Lu writes:
> disassembly of libc.so samples extracted from real Android devices
> reveals that defective versions of memchr are present until Android 4.3,
> API level 18.
Correction, up to API level 22 on architectures without specific
implementations of memrchr, as these issues suggest:
h
I was looking at a program that used PID & 0x as an arbitrary
identifier. Not directly related to this patch but it made me think
about what the limits are on process, user, and group IDs.
Here is what POSIX Issue 7 says in the documentation in
[1]:
The implementation shall support one or mo
Collin Funk writes:
> The implementation shall support one or more programming environments in
> which the widths of blksize_t, pid_t, size_t, ssize_t, and suseconds_t
> are no greater than the width of type long.
Oops, I only quoted the part mentioning pid_t. Two other important
parts:
* nlink
17 matches
Mail list logo
