Re: [dev] [sbase] Portability

From: Dimitris Papastamos <sin_AT_2f30.org>
Date: Thu, 26 Nov 2015 09:36:38 +0000

On Thu, Nov 26, 2015 at 01:52:23AM -0500, Random832 wrote:
> I downloaded and built sbase for my OSX system to test the cal program,
> and noticed (and fixed locally) several issues.
>
> Before posting any patches, I wanted to ask - philosophically speaking,
> how much effort should sbase put towards supporting systems that don't
> support the latest-and-greatest POSIX functions? Three functions were
> missing (utimensat, clock_gettime, and fmemopen), and fmemopen in
> particular required an extensive implementation, which I found online
> (https://github.com/NimbusKit/memorymapping) rather than writing myself.
>
> Also, if these are added should they go in libutil or a new "libcompat"?

Yes this is kind of a known issue. I would like to stick to the latest
interfaces. Unless of course there is no reason and we do not benefit from
using those latest interfaces.

Sometimes we come across good interfaces that are not standardized.
We just put an implementation in libutil. This is similar to how OpenBSD
handles the portable versions of the programs.

In regards to the functions you highlighted:

* utimensat is cool and I would like to keep it. I had the same
problem on DragonFlyBSD. I went ahead and implemented the utimensat()
syscall for it and send a patch.
* clock_gettime is quite useful and is known not to work on OSX. I have
a patch[0] for another project to address this problem.
* fmemopen is rarely used but I think it simplifies the code in grep.

I am open to recommendations as long as we do not sacrifice anything from
using the latest interfaces.

Cheers,
Dimitris

[0] http://u.2f30.org/sin/patches/ratox/0001-Add-OSX-replacements-for-certain-functions.patch
Received on Thu Nov 26 2015 - 10:36:38 CET

This archive was generated by hypermail 2.3.0 : Thu Nov 26 2015 - 10:48:10 CET