Hacker News Reader

Comment by vxNsr | Hacker News Reader

He claims that your code will be easy to port but then goes straight to Linux system calls.

Still I like the idea. This is something that should be covered in a CS 102 type course. I know way to many cs guys who have no idea how to debug, let alone how their is being implemented.

View on HN

> He claims that your code will be easy to port but then goes straight to Linux system calls.

Many linux developers believe "code is portable" means "can run on different linux distros".

Edit: To be fair, he said architectures, and i think he meant CPU architectures, i.e. AMD64 and i386.

But still, Linux syscalls are different on each architecture.

Indeed, stupidly different. Different syscall numbers, different argument orders, different values for constants, different struct layouts, ... Some architectures, like MIPS, are particularly bad, with nods to Irix compatibility thrown in.

The BSDs are all exactly the same for every architecture, sane.

Does that mean you can run Irix binaries on MIPS Linux?

This dates back to how Linus did the first non-x86 port of Linux to the DEC Alpha. Rather than copying the x86 linux syscall conventions, he used the DEC OSF/1 syscall conventions to ease bootstrapping. This is a perfectly sane approach. But he probably should have reverted to a native syscall numbering rather than leaving this bootstrapping hack in place.

Different platforms have different sets of registers and alignment requirements. You want to pass things in registers if possible. If you want to avoid inefficiency, you need platform differences. And this is all hidden from users and even developers anyway.

...which is why he used the SYS_ #defines.

When I was learning C, I loved Plauger's book on the standard library for just that reason; it's very informative to be guided through the implementation of the whole thing, not only to see how it works, but it's also a good way just to be introduced to everything in it without any magic. It's an excellent 2nd book on C, I think.

Plauger is one of my unsung heroes.

I discovered a little book by him after wading thru recursive descent parsers chapter by Herb Schildt... I don't want to get down on Schildt, I enjoyed that too, he showed some cool stuff..

but Plauger had me thinking that programming could be a craft, an art, a noble intellectual pursuit.

What is the title of the book by Plauger you are referring to?

"The Standard C Library"

Thank you.

I've written Windows programs without the std library. The Win32 has plenty of replacement functions you can use instead though so it's much less work than what's presented here.

You get the same sorts of benefits though.

Win32 is itself a layer on top of the syscalls, and already provides much of the functionality of the C standard library.

Yes, that was partly my point.

You can get reduced executable size and a lack of dependencies on various msvc*.dlls, without giving up much of the functionality of the C standard library and without having to write it all yourself.

Fine, but you get this thanks to already being linked with these megagodzillas like kernel32.dll. Try without them.

A program which isn't linked against the Win32 stuff is an invalid program, since syscalls in Windows are not at all stable.

On windows nt, ntdll gets loaded in all processes, it's hardcoded in the kernel (http://gate.upm.ro/os/LABs/Windows_OS_Internals_Curriculum_R...). That's where the loader resides, so you can't go without it. And that's where all the Zw/Nt* functions/ i.e. where the syscalls are.

So you can't really go without it.

Except the new picoprocesses, which don't get ntdll (or anything really, I guess).

Suppose you want to port to some architecture not supported by libc. If you were using libc you would have to find a replacement that works and targets that arch or port libc yourself. If you wrote everything from scratch, instead, you just have to read the specification and add support to your code. That's what I meant.

Of course, if your target archs are all supported by libc, porting is much easier with libc.

Depending on the scope of your project porting libc itself might be good idea. Then you simplify porting any tools you need that also use libc. Then you can port a few extra dependencies, then more tools...

What are some archs that arent't supported by libc? Just embedded systems?

Well, not if you expect that you will have exactly the same time/space behaviour and pre/post conditions.

This is why lots of embedded, secure and defense software doesn't use standard libraries, and printf will instead be called sio04583 or something....

Also.. Don't forget that you can get gcc to get rid of unused code when compiling static executables, and use sstrip (yes, two 's' - it's a different program) to strip even more, if it's an ELF binary...

Portability is impossible without the standard library.

What ? You just write your OS layer for each platform and it's portable.

True. The OS layer you write (and port to other OSes) is called "the standard library". :-)

A .h file with different syscalls IDs and perhaps a few inline functions is hardly a standard library though

Not exactly syscall ids: I built network services (telnet daemon, snmp client and server, DNS) that compiled without change for win32 (both on Windows and some embedded win32 compatible abomination) and Linux with just a handful of defines and function wrappers as part of a contract once. A lot of apps can get away with very narrow interfaces to the OS.

> A .h file with different syscalls IDs

That's not portable even across versions of the same OS, many OS don't support raw syscalls and don't make any guarantees about them. That's why you can't statically link libc on OSX for instance, libSystem is literally the system's interface and necessarily dynamically linked.

That would be the few inline functions so to abstract a bit the syscalls.

It doesn't abstract anything, if the syscall changes your "abstract a bit" will be broken all the same. On many if not most OS the machine code side of the syscalls can change with no notice, Windows has changed syscalls in minor revisions, Go broke several times during the Sierra beta due to syscall changes (because it handrolls gettimeofday(2) whose assembly calling convention changed).

The proper abstract interface on non-linux systems is the standard library.

But at least now you know what's in there, what's going on behind the scenes. And on top of that, it's filled with all sorts of brand new bugs and vulnerabilities! ;-)

As far as PortableOSIX compliant syscalls are concerned, they are literally portable.

The userspace/kernel interface for invoking syscalls which the OP calls with assembly code is obviously not portable. Not even between similar OSs on one architecture and absolutely not between architectures.

POSIX only specifies a set of C library functions. Once you stop using them, you are on your own.

> He claims that your code will be easy to port but then goes straight to Linux system calls.

These are nowadays supported by Windows and few BSDs too, who needs more portability than that :)

"Supported on Windows" is a strong claim. They are supported in the Linux subsystem, but asking your users to install that seems far fetched to me.

> He claims that your code will be easy to port but then goes straight to Linux system calls.

Well, it is hard to see an alternative to that outside supplying your own OS with the library...

Reply on news.ycombinator.com