Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does C have the best file API

maurycyz.com

Post reply on HN
Print view View original

131–140 of 169 posts

Re: Why does C have the best file API

#131

Post by ajross »

t-3 wrote: post #109
ajross wrote: post #20

Earlier quoted context omitted.

I think this is sort of missing the point, though. Yes, mmap() is in POSIX[1] in the sense of "where is it specified". But mmap() was implemented in C because C is the natural language for exposing Unix system calls and mmap() is a syscall provided by the OS. And this is true up and down the stack. Best language for integrating with low level kernel networking (sockopts, routing, etc...)? C. Best language for async I…

>> Best language for SIMD integration? C Uh, no. C intrinsics are so much worse than just writing assembly that it's not even comparable.

Agree to disagree there. For casual "I need to vectorize this code" tasks, modern compilers are almost magic. I mean, have you looked at the generated code for array-based numerics processing? It's like, you start the process of "vectorizing" the algorithm and realize the compiler already did 80% of it for you.

Re: Why does C have the best file API

#132

Post by ajross »

nickelpro wrote: post #24
ajross wrote: post #20

Earlier quoted context omitted.

I think this is sort of missing the point, though. Yes, mmap() is in POSIX[1] in the sense of "where is it specified". But mmap() was implemented in C because C is the natural language for exposing Unix system calls and mmap() is a syscall provided by the OS. And this is true up and down the stack. Best language for integrating with low level kernel networking (sockopts, routing, etc...)? C. Best language for async I…

If we're going to be pedantic, mmap is a syscall. It happens that the C version is standardized by POSIX. The underlying syscall doesn't use the C ABI, you need to wrap it to use it from C in the same way you need to wrap it to use it from any language, which is exactly what glibc and friends do. Moral of the story is mmap belongs to the platform, not the language.

No, that's too far down the pedantry rabbit hole. "mmap()" is quite literally a C function in the 4.2BSD libc. It happens to wrap a system call of the same name, but to claim that they are different when they arrived in the same software and were written by the same author at the same time is straining the argument past the breaking point. You now have a "C Erasure Polemic" and not a clarifying comment.

If you take a kernel written in C and implement a VM system for it in C and expose a new API for it to be used by userspace processes written in C, it doesn't magically become "not C" just because there's a hardware trap in the middle somewhere.

mmap() is a C API. I mean, duh.

Re: Why does C have the best file API

#133

Post by dekhn »

dataflow wrote: post #48
dekhn wrote: post #33

Earlier quoted context omitted.

Address space size and RAM are two different things.

What they said is correct regardless of that though?

I'm pretty sure the parent post to mine was updated from "RAM" to "address space", although I'm not 100% sure.

Re: Why does C have the best file API

#134

Post by zadikian »

groundzeros2015 wrote: post #125

nobody mentioning the "file system as a noSQL database comment". I found most of the friction when using bash/unix style tools when I tried to put everything in structured files that needed parsing. Once you see folder/files as the structure these tools work great. It's also interesting to me that many noSQL starts from the assumption that relations are too complex, and that trees are preferred.

NoSQL was more of a convenience thing during that trend. You might have some bag of nested attributes that maps perfectly fine onto relations, but it's cumbersome for someone who just wants to load it all into an object, edit, then resave. People used to use ORMs to get around that, then NoSQL became popular, and now you can just use jsonb in SQL while still maintaining relations for other things.

This doesn't say much about the horizontal scaling that NoSQL systems were really designed for, but most people getting on that train didn't need that kind of scale.

Re: Why does C have the best file API

#135

Post by lxgr »

elehack wrote: post #126
amluto wrote: post #122

Earlier quoted context omitted.

> Little endian is superior because you can cast between integer types without pointer arithmetic I’ve heard this one several times and it never really made sense. Is the argument that y you can do: short s; long *p = (long*)&s; Or vice versa and it kind of works under some circumstances?

Yes. In little-endian, the difference between short and long at a specific address is how many bytes you read from that address. In big-endian, to cast a long to a short, you have to jump forward 6 bytes to get to the 2 least-significant bytes.

Wow, I've been living life assuming that little endian was just the VHS of byte orders with no redeeming qualities whatsoever until today. This actually makes sense, thank you!

Re: Why does C have the best file API

#136

Post by lxgr »

Dwedit wrote: post #12

Using mmap means that you need to be able to handle memory access exceptions when a disk read or write fails. Examples of disk access that fails includes reading from a file on a Wifi network drive, a USB device with a cable that suddenly loses its connection when the cable is jiggled, or even a removable USB drive where all disk reads fail after it sees one bad sector. If you're not prepared to handle a memory acces…

Do these really ever result in access failures instead of just hangs? How are they surfaced to processes?

In my experience, all these things just cause whatever process is memory mapping to freeze up horribly and make me regret ever using a network file system or external hard drive.

Re: Why does C have the best file API

#137

Post by lxgr »

zahlman wrote: post #14

Aside from what https://news.ycombinator.com/item?id=47210893 said, mmap() is a low-level design that makes it easier to work with files that don't fit in memory and fundamentally represent a single homogeneous array of some structure. But it turns out that files commonly do fit in memory (nowadays you commonly have on the order of ~100x as much disk as memory, but millions of files); and you very often want to read…

> mmap() is a low-level design that makes it easier to work with files that don't fit in memory

It also often saves at least one copy operation (page cache to/from an application-level byte array), doesn't it?

Re: Why does C have the best file API

#138

Post by pajko »

qalmakka wrote: post #88
ajross wrote: post #20

Earlier quoted context omitted.

I think this is sort of missing the point, though. Yes, mmap() is in POSIX[1] in the sense of "where is it specified". But mmap() was implemented in C because C is the natural language for exposing Unix system calls and mmap() is a syscall provided by the OS. And this is true up and down the stack. Best language for integrating with low level kernel networking (sockopts, routing, etc...)? C. Best language for async I…

> C is the natural language for exposing Unix system calls No, C is the language _designed_ to write UNIX. Unix is older than C, C was designed to write it and that's why all UNIX APIs follow C conventions. It's obvious that when you design something for a system it will have its best APIs in the language the system is written in. C has also multiple weird and quirky APIs that suck, especially in the ISO C libc.

Here, this is not C: https://github.com/jserv/unix-v1/blob/master/src/lib/open.s

Re: Why does C have the best file API

#139

Post by [deleted] »

fc417fc802 wrote: post #97
fulafel wrote: post #80

Earlier quoted context omitted.

It's very different since at random points of your program your signal handler is caleld asynchronously, and you can only do a very limited signal-safe things there, and the flow of control in your i/o, logic etc code has no idea it's happening. tldr; it's very different.

Well at least in this case the timing won't be arbitrary. Execution will have blocked waiting on the read and you will (AFAIK) receive the signal promptly in this case. Since the code in question was doing IO that you knew could fail handling the situation can be as simple as setting a flag from within the signal handler. I'm unclear what would happen in the event you had configured the mask to force SIGBUS to a diff…

[deleted]

Re: Why does C have the best file API

#140

Post by benj111 »

pjmlp wrote: post #118
benj111 wrote: post #117

Earlier quoted context omitted.

On the other hand some people have things to ward off evil demons, and aren't bothered by evil demons. The parent has actually done the thing, and found no issues, I don't think you can hand wave that away with a biased metaphor. Otherwise you get 'Goto considered harmful' and people not using it even when it fits.

As proven by many languages without native support for plain old goto, it isn't really required when proper structured programming constructs are available, even if it happens to be a goto under the hood, managed by the compiler.

My point is it's bad debating style. 'Everyone knows C is bad for all kinds of reasons ergo, even when someone presents their own actual experience, I can respond with a refrain that sounds good'

Not using goto because you've heard it's always bad is the same kind of thing. Yes it has issues, but that isn't a reason to brush anyone off that have actual valid uses for it.

Post reply on HN