Is it time for a libc_fixes library yet?

[Stephen J. Butler]

I just noticed that the getdelim code manipulates the FILE* directly, so
that's not allowed in your lib. But it's essentially just filling a buffer
with data, processing it, and checking feof()/ferror() along the way.
Nothing complicated you can't reproduce with std api's.

On Mon, Jul 3, 2017 at 4:01 PM, Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

> No reason at all, other than how I discovered them along the way! I have
> used AOS exclusively for months; I think these were the two original ones I
> replaced, last year.
>
> I will see how these can replace the existing ones.
>
> In the end, I sincerely hope this helps make supporting these older
> systems so easy that it is a non-issue for port developers. No tickets
> means happy port devs and happy users!
>
> Ken
>
> On 2017-07-03, at 1:56 PM, Stephen J. Butler wrote:
>
> Is there a reason to not use the Apple/FreeBSD Libc versions? I see you
> used the same one they did for memmem and wcsdup.
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> stdio/FreeBSD/getdelim.c.auto.html
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> stdio/FreeBSD/getline.c.auto.html
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> string/FreeBSD/strndup.c.auto.html
>
> https://opensource.apple.com/source/Libc/Libc-1158.50.2/
> string/FreeBSD/strnlen.c.auto.html
>
>
>
>
> On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham <
> ken.cunningham.webuse at gmail.com> wrote:
>
>> I see a general frustration with the current situation has led things to
>> move along rather quicker than I had originally thought they might.
>>
>> I will never know as much about licensing as you do. I hope this can be
>> worked out to advantage. I notice most of this code is already being pasted
>> in as patches, and it's in the files directory of many ports...
>>
>> Right now this library is a dylib, as you previously recommended. Hope
>> that helps. Will seek out any more liberal implementations. Most of these
>> came for Apple open source, I think, over the past year.
>>
>>
>> K
>>
>>
>> On 2017-07-03, at 1:09 PM, Rainer Müller wrote:
>>
>> > On 2017-07-03 19:07, Ken Cunningham wrote:
>> >> So the last 10 or so tickets in trac seem like they are all for
>> >> basically the same issue - a few missing symbols from libc prior to
>> 10.7.
>> >
>> > Well, I would take this as a reason to just drop support for such an old
>> > OS release... I know, I cannot convince you to do that yet. ;-)
>> >
>> >> It is easy enough, but time consuming, to patch each individual source
>> >> file that is missing the definition (there might be several, also, so
>> >> you might have to do it multiple times in different files).
>> >>
>> >> With this library of these missing functions
>> >> <https://github.com/kencu/snowleopardfixes>, all of them from the
>> Apple
>> >> open source website IIRC, all you need to do is the following in the
>> >> Portfile:
>> >>
>> >> if{${os.platform}eq "darwin"&& ${os.major} < 11} |{ depends_lib-append
>> >> port:snowleopardfixes configure.ldflags-append -lsnowleopardfixes } |
>> >
>> > Taking a quick look at this library, all implementations seem to be
>> > covered by GPL-2+.
>> >
>> > That makes this library not suitable for many ports, as the result after
>> > linking would no longer be distributable. It would be better to use
>> > implementations under a non-copyleft license such BSD, MIT, ISC, etc.
>> >
>> >> It could be better named, perhaps libcfixes, as it applies to 10.4 to
>> >> 10.6, not just SnowLeopard.
>> >
>> > I would not declare theses as "fixes", but rather as "supplements"
>> > providing additional functions not available in libc.
>> >
>> >> Addendum 1
>> >>
>> >> I have a header in there as well to provide the function definitions,
>> >> but that header can cause trouble by bringing in other #defines, and it
>> >> seems that no port actually needs the header. Perhaps the header idea
>> >> can be improved by someone with more knowledge of #include_next, etc,
>> or
>> >> more specific defines.
>> >
>> > I guess you would see compiler warnings about implicit declarations?
>> >
>> > As an example, if the compiler assumes a declaration like
>> >  int strnlen(int, int)
>> > instead of
>> >  size_t strnlen(const char *s, size_t maxlen)
>> > that could still work as long as sizeof(int) == sizeof(char*), because
>> > the parameters are passed with the same calling convention. However,
>> > this might fail in other cases at runtime (structs, floats, ...).
>> > Although it might still work correctly for builtins, for which the
>> > compiler actually knows the declaration.
>> >
>> > To avoid exposing too many functions, the declarations could be
>> > controlled with preprocessor conditions.
>> >
>> > #if !defined(SNOWLEOPARDFIXES_MANUAL_MODE) ||
>> >    defined(SNOWLEOPARDFIXES_STRNLEN)
>> > size_t strnlen(const char *s, size_t maxlen)
>> > #endif
>> >
>> >> Addendum 2
>> >>
>> >> As we have said before (last year) this library could be automatically
>> >> linked in by base. That would cause trouble with the ports that have
>> >> already patched in a def, tho.
>> >
>> > If this library itself were in base, adding new functions would require
>> > a new base release. So you would still need local patches, which later
>> > break with the new release...
>> >
>> > base could automatically add it as a dependency, with the port being in
>> > our ports tree.
>> >
>> > Rainer
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170703/9c71975d/attachment-0001.html>