GNU Pth saw its last release in 2006. I don't think it will be revived,
nor will it have real use any more, because new operating systems come
with already implemented. (For example, this was the case
with Haiku and is the case with Fuchsia OS.)
The option --enable-threads=pth and / are
incompati
Thanks, removing that old cruft looks good to me too.
At some point someone with energy could remove the corresponding code (as the
'configure' delay can be bothersome) but that's low priority.
The old Solaris threads facility was needed for portability to the
ancient Solaris 2.4. Solaris >= 2.5.1 has POSIX threads.
Even though Solaris nowadays probably still supports this API, you can
bet that 100% of all applications use the POSIX threads API. There is
no point in --enable-threads=solar
Hi,
I'd like to remove the mentions of the following old platforms from
the gnulib documentation:
Platform Comments
glibc < 2.2
Linux libc5
Mac OS X < 10.5
AIX < 5 end of support in 2004 (AIX 4.3.3 released in 1999)
HP-UX < 11 end of support in 200
Pádraig Brady wrote:
It would be nice to have areadlink_with_size treat 0 as auto select some lower
bound.
Yes, that sounds good. However, I didn't see why that would entail changing
SYMLINK_MAX from 1024 to 1023, or why the patch would affect the documented API.
How about the attached patc
> 2019-07-02 Bruno Haible
>
> renameatu: Fix test failure on MSVC.
> * lib/at-func2.c (at_func2): Fail with ENOENT if file1 or file2 is the
> empty string.
There was no comment in two days. So I'm pushing this.
Bruno
> Therefore I think it would be good to add a "Shrink BUF before returning it."
> logic also to
> areadlink-with-size.c
> areadlinkat-with-size.c
> etc.
Done as follows:
- For areadlink-with-size, areadlinkat-with-size, xgethostname, xgetdomainname
by shrinking the result before returning
Pádraig Brady wrote:
> + areadlink-with-size: guess a lower bound with 0 size
The patch looks good to me. Except that now, with the shrink-before-return in
place, the term "lower bound" is no longer appropriate. A better term is
probably "Initial memory allocation".
Bruno
On Thu, Jul 4, 2019 at 4:24 AM Pádraig Brady wrote:
> BTW this would allocate more for empty symlinks,
> but they're rare: https://lwn.net/Articles/551224/
Interesting (re)reading. Patch looks fine. Thanks.
