Return value

>Return value
>If the function succeeds, the return value is nonzero.
>If the function fails, the return value is zero. To get extended error information, call GetLastError.
>winapi

Attached: 488606CC34344B4AA60BFFDED8649860.png (344x398, 189K)

What's the problem here?
C does this too

*throws exception*

It works entirely opposite to how the Unix shell works (0 is success, nonzero is failure where each number corresponds to an error type) and makes no sense.

That's fucking retarded. Using raw integers for error codes is bad enough, but using 0 for failure is even worse.

1 is true, 0 is false, which one sounds more like success to you?

The most likely situation is that you have one kind of success and many kinds of failure. How many kinds of zero and how many kinds of nonzero values are there?

0, for no error. Also, it returns an integer value not a boolean value.

Posix has the same shit with errno.

Errno is the biggest mistake in C.

I think 0 for success and -errno for error is a pretty nice way to handle it.
But 0 for false and 1 for true (using the proper bool type) for anything that is a predicate.

Your point is irrelevant once we've committed to using the return value solely to report a success or failure. Which is preferable for a user-mode C API because we don't have to keep passing the error code down and instead just store it in TLS so only the code that cares about the error needs to expend LOC and cycles on dealing with it.
These APIs return BOOL as a stand-in for a real boolean because there is no boolean type in the older C specifications.

Win32 might, but Unix doesn't. int main returns an error code where 0 is no error. Getting a zero back and having to call another function to figure out what went wrong might make sense in winbloat, but it's straight forward and easy to parse in Unix.

>Your point is irrelevant once we've committed to using the return value solely to report a success or failure.
Consistency is always better. Even if you're storing the actual error in a thread local variable, the return value indicating the existence of an error should be tested the same way. Doing otherwise invites confusion and bugs.
>Which is preferable for a user-mode C API because we don't have to keep passing the error code down and instead just store it in TLS so only the code that cares about the error needs to expend LOC and cycles on dealing with it.
You're going to be returning an int far down the stack either way. It's not going to make a difference whether that int is a 1 or a real error code.

This would be hell in a multithreaded environment

Thread-local variables exist as a "patch" for that kind of shit.

Yeah, both GetLastError() and errno are thread-local. If they weren't, nothing would fucking work.

Yeah, this.

>What is errno()

A mistake

Winapi functions often return a HANDLE (typedef for void*). It makes sense to consider 0 (NULL) failure and non-0 success. They extended this logic to the rest of the functions for the sake of uniformity.

In unix a function returns 0 for success and -1 for failure. The error code is saved in errno, not returned.

I've worked with many APIs that record the error in the return value rather than errno and that's how they do it.

HANDLEs are retarded like the rest of winapi.

mods need to put you faggots back into a text only board. this is a pc gaming board. coders and linux faggots not allowed

Except WinNT and OS/2 and therefore COM inverted this with the concept of HRESULTs again, which return zero (or rarely, a positive value) for success and a negative value which encodes the source and details of an error in the bottom 31 bits.

Back to you go.

dumb brat poster

nigga just throw an exception

wtf caveman company requires raw winapi

cute brat, never seen this shot before

Attached: 1559023861025.png (344x398, 214K)