Windows has different types of status codes, `HRESULT` and `NTSTATUS` for instance, that allow for representing both success and failure values. This allows for macros like `FAILED` and `NT_SUCCESS`. One example of a success status code is `STATUS_PENDING` that indicates an IO is not yet complete.

I'm trying to map similar style status codes in Linux. I have a (WIP) cross platform library that uses the above type of status codes on Windows (user mode and kernel mode). I have my own "FAILED" macro that wraps the above macros. I need an equivalent for Linux for it all.

I've looked around and haven't found anything interesting/helpful. For any system/platform function (sockets, thread, locks) that might return and error, I need to make sure it is converted to the appropriate status code type. Windows has lots of helpers for things like this, but I'm not sure about Linux.

Psuedocode example:

```
MY_STATUS SendAsync(...) {
   ASYNC_OPERATION* Operation = MY_ALLOC(...)
   if (Operation == NULL) {
       return MY_OUT_OF_MEMORY_ERROR; // Error status
   }
   // Build the operation
   MY_STATUS Status = QueueOperation(Operation);
   if (MY_FAILED(Status)) {
       return Status;
   }
   return MY_STATUS_PENDING; // Success status
}

```

The caller should then be able to have the following code:

```
MY_STATUS Status = SendAsync(...)
if (MY_FAILED(Status)) {
   // Bail
}
// Handle success

```

I think the crux of the problem is that I don't know how to stuff status codes from system/platform function calls into a generic type that supports success/fail. Generally, it looks like all the status codes are positive, so I could just say my success error codes are `<= 0`. But I'm not sure that's a great solution.

To be clear, since it was proposed that [this question](https://stackoverflow.com/questions/12352922/in-windows-is-there-any-way-to-convert-an-errno-into-an-hresult) might the answer, I'm not trying to force the Linux status/error codes into `HRESULT` format explicitly. I'm just trying to find *some way* to represent error codes as either success or failure. If I have to convert system error codes (negate them?) along the way, that's acceptable. If there is no real solution to this problem, then that would be an acceptable answer (though not desired), and I'll have to find some work around.