LLDB_DISABLE_POSIX

Frequently I see checks against LLDB_DISABLE_POSIX, and other times i see specific OS checks. It seems to me like #if LLDB_DISABLE_POSIX is equivalent to #if defined(_WIN32). If this is correct, any objection to me marking LLDB_DISABLE_POSIX as deprecated and slowly changing conditionals over to #if defined(_WIN32) instead? It’s easier for me to reason about and I don’t have to spend time thinking about what other platforms might be affected that way.

From a quick survey it seems as if most of the uses of LLDB_DISABLE_POSIX are for turning off POSIX specific features, not turning on Windows specific ones. LLDB_DISABLE_POSIX seems more appropriate for this that !_WIN32 or whatever. For instance, if we wanted to port lldb to OpenVMS, we could just keep the defines as they were and add LLDB_DISABLE_POSIX to the OpenVMS makefile (though I'm sure it has a POSIX layer of some level of fidelity, but using that or the native VMS calls would be up to the person who was doing the port...)

It does seem like we are using POSIX to mean UNIX, so that some UNIX'es that aren't fully POSIX compliant succeed the checks, and then need #ifdef FREEBSD or whatever. Not sure it's worth cleaning this up, however.

Jim

Well, ideally we should strive to have any system calls get moved into the Host layer anyway, and so that problem would solve itself by by just getting rid of checks to LLDB_DISABLE_POSIX. So maybe I’ll revisit this question after I can get rid of more of these uses of LLDB_DISABLE_POSIX and put more stuff into Host layer.

Well, ideally we should strive to have any system calls get moved into the Host layer anyway, and so that problem would solve itself by by just getting rid of checks to LLDB_DISABLE_POSIX. So maybe I'll revisit this question after I can get rid of more of these uses of LLDB_DISABLE_POSIX and put more stuff into Host layer.

We didn't have the time to come up with a complete host layer when we started working on lldb; we needed to get something up and working and other abstractions were more important than that. So a bunch of unix'y assumptions crept in all over the place. Cleaning that up seems the right way to address this!

Thanks...

Jim