#define for a success or failure

Question

Hello,

I am using a API that has a macro for success which is "NT_SUCCESS". However they don't have one for failure. So normally I have to do this.

if(something failed)
    return !NT_SUCCESS;
else
   return NT_SUCCESS;

Having the !NT_SUCCESS I don't think is very readable. So I decided to do this:

#define SUCCESS NT_SUCCESS
#define FAILURE (!NT_SUCCESS)

EDIT =============================

#define ENT_NOERR 0 /* No error */ 
#define NT_SUCCESS ENT_NOERR /* synonym of ENT_NOERR */ 

This is how NT_SUCCESS is declared, Would it still be ok to do what I have done.

Would that be ok?

Many thanks for any suggestions,

Answer 1

that would be ok

Answer 2

Are you sure that logically negated value of NT_SUCCESS is an indication of failure?

Answer 3

I would suggest to put the FAILURE define in parenthesis:

#define FAILURE (!NT_SUCCESS)

Answer 4

If you want to be truly paranoid, you should add parentheses:

#define FAILURE (!NT_SUCCESS)

Answer 5

Well, it actually depends. It's a little unusual for you to return the same error values as an API you're calling. The only times I can see this would be required is if either:

• you're actually returning a value back from a callback initiated within the API.
• you're replacing code in the API so have to follow the same rules.

It may be that NT_SUCCESS is 0 but a failure can be indicated by any other integer. That means that !NT_SUCCESS is not the only value that means failure.

Of course, you're free to pass back from your API whatever values you wish, I wouldn't necessarily make them the same as the ones from the API you're using. You could quite easily return a failure indication (true = fail, false = success) which would make your code the much nicer looking:

return something_failed;

or, at worst,

if (something_failed) return TRUE;
: : :
return FALSE;

Answer 6

I would add parentheses for good measure, but otherwise you should be OK:

#define FAILURE (!(NT_SUCCESS))

This is "just in case", to prevent bad definitions such as #define NT_SUCCESS 1+1. Of course, no sane implementation would do this, so your definition should be okay too. But it can't hurt to be paranoid. :-)

Answer 7

It's not ok, at least not until you know how NT_SUCCESS is defined. It can be defined as #define NT_SUCCESS 1 or as #define NT_SUCCESS TRUE

In the second case it makes sense to write !NT_SUCCESS, so your code is ok, but in the first case, writing !NT_SUCCESS means !1, which doesn't make any sense. In the second case you would be better off with:

#define SUCCESS NT_SUCCESS
#define FAILURE -1 //or other value which makes sense

It's up to you.

Answer 8

This can not possibly be correct. Surely you are supposed to return some kind of error code that gives the caller a chance to find out why it didn't work?