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
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
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
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
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
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
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))). */
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
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
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:
> 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
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
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
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
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
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
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
17 matches
Mail list logo
