[Pxtl]

It doesn't double the security surface area if the abstracted API goes through the low-level API. The outer one is just chrome, and so the risks of screwing something up there is far lower.

Unless you're using a trash language where even simple wrappers could buffer underrun or something.

[lmz]

Isn't there the issue of modifying the state enough through the low-level API such that it breaks the assumptions of the high-level one?

[withinboredom]

The high level API shouldn’t care about state. In other words, your “readers” should merely aggregate state and your “writers” should only care about subsets of state.

Think about file permissions in Linux. Running ls just shows you gross file perms (current user, group, and global) but you can also grant access to other individual users, or even make a file immutable that still shows up as writable to ls. The high level api doesn’t know or care about the low level state except where it is relevant.

[eru]

Just say that you don't support mixing both APIs.

[lazyasciiart]

Now you’re telling users to check the source code of any tools they use with your stuff? “We recommend using ToolOne only on content you do not also manage with ToolTwo”

[eru]

See how libfuse handles it with their low level and high level APIs.

[actionfromafar]

That’ll fix it. ;-)

[Pxtl]

Yes. But that's the high-level API's problem. That's a problem with any abstraction really. "What if there's something in the thing we're abstracting that doesn't fit the abstraction" isn't really a problem with the "two API" approach, it's a problem with abstraction.

The high-level API needs to handle that case, if nothing better than having internal assertions that throw if it hits a case it's not designed to accommodate.

(also I'm annoyed with myself that I wrote buffer underrun in my first post instead of buffer overflow and now it's too late to edit).

[cylemons]

You did make me search what a buffer underrun was and I think it was a good read