Show HN: Libcox – A C Library for Cross-Platform System Calls | Hacker News Reader

Show HN: Libcox – A C Library for Cross-Platform System Calls

libcox.net

47 pointssymisc_devel27 comments

Aside from being C and "lightweight" I wonder when you'd want to pick this instead of POCO or ACE...

Not sure if climbing this high on HN on a U.S. holiday indicates a real need or clever marketing for this new project, but congratulations to them for getting the word out.

Thanks also to you for sharing a couple well-established alternatives.

A few more (particularly nspr and apr): http://www.shlomifish.org/open-source/portability-libs/

As it explains quite clearly, this is "portable system calls". Lightweight indeed, it's the whole point!

So if you ask this question, you might as well ask why system calls are not more expansive in their capabilities.

I think there's a reason, system calls are much simpler. They are building bricks. If you want to layer something complex on top, you're free to do so.

About your suggestions, ACE's documentation is particularly bad. I wouldn't recommend it to anyone.

This project is using the phrase "system call" idiosyncratically / incorrectly: by it they mean "calls to the system() function", not "low-level OS facilities". POCO and ACE seem to be about actual system calls (network programming, threads, pipes, etc.) They're for very different purposes.

libcox is for when your existing code would do something like system("uname") or system("ls") (... except not even with system(), with popen() or something), and you want it portable to Windows.

Thought it was either written by Russ Cox or it had something to do with Roosters. But seriously, it's more of a personal problem if someone can't make the minute mental leap to discriminate between cox and cocks-the name is perfectly fine and doesn't need to be changed.

Why use command processing (e.g. `libcox_exec(pHandle,&pResult,"uname",-1)`) rather than plain function (could be `libcox_uname(pHandle, &pResult)` for instance) ?

no need to release a new version by a adding a new public API function each time a command is added. You would simply create a new foreign command in your application, register it via libcox_register_command()[1] without modifying the library core.

[1]: http://libcox.net/c_api/libcox_register_command.html

    rc = libcox_exec_fmt(pHandle,&pResult,"ls '%s'",zDir); /*Don't forget the single quotes around 'zDir' */

This is either insecure, or so different from a shell as to make it not worth using shell syntax.

I really like the concept though. Took me to figure out what the concept is because "system calls" doesn't mean "shell commands" to me, but having figured that out, operating on shell commands has a lot of things going for it.

Hi, this is due to the fact that zDir may contain spaces especially under windows which confuse the command processor to interpret it as multiple arguments and not a single one as with single or double quotes (http://libcox.net/arch.html)

What happens if zDir contains single quotes?

You need to escape them, like in every other instance where strings may contain control characters.

That'd be my guess, at least, but, i guess, single quotes aren't valid characters for zDir.

So what are the quote parsing rules for libcox, and given an arbitrary string, how do I correctly escape them?

(In the absence of this, and certainly in the absence of official docs/examples that do the right thing, that's a security vulnerability waiting to happen.)

String escaping follows the same rules of C/C++ or you could use the str_escape command to do job for you.

Why do you take care of space escaping but not others (quotation marks)? This might lead to false expectations, i.e. that you take care of everything, security-wise.

I don't know how they managed to do it, but on the mobile version of the site, none of the useful links are actually links...

Very cool project! But I agree with the comments about the name is unfortunate

Reply on news.ycombinator.com