[haiku-commits] Re: haiku: hrev47655 - headers/posix src/bin src/apps src/kits src/kits/tracker
- From: Paweł Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Wed, 27 Aug 2014 19:51:02 +0200
2014-08-27 19:33 GMT+02:00 Alexander von Gluck IV <kallisti5@xxxxxxxxxxx>:
> On , Jérôme Duval wrote:
>
>> 2014-08-27 18:02 GMT+02:00 Alexander von Gluck IV <kallisti5@xxxxxxxxxxx
>> >:
>>
>>> Hm, I agree but a lot of projects may not accept these patches.
>>> Windows provides only "string.h", so changing to strings.h breaks things
>>> that
>>> build on Windows + UNIX.
>>>
>>> I just tried to get a change into Mesa and they rejected as it "works
>>> everywhere else at the moment"
>>>
>>>
>> Just search for "strings.h patches", that's not like we're the first
>> to apply to the specs anyway.
>>
>
> strings.h only defines two functions... we're going to require a large
> number
> patches across all open source software for two functions?
>
> This is a one line fix. #include <strings.h> in string.h
>
> Hell, make it a 3 line fix and put some comments saying it is "for legacy
> compatibility"
>
> I agree POSIX says it should be done the way it is now and it is
> correct... however
> every Linux / UNIX system I can find rolls these functions into string.h
> as well. As Linux
> is what 99% of those people writing POSIX software for these days, why not
> go with the flow
> here? (Even though every other OS is wrong and stupid for screwing up
> POSIX :P)
>
That's just creating unnecessary problems. For the compatibility sake this
functions are usually defined in string.h as well (apparently, that's where
they originally were many years ago) and we should do the same if
_GNU_SOURCE is defined (and perheps _BSD_SOURCE as well). No reason to make
things more difficult than they really are.
Paweł
Other related posts:
