A2C_EncodeDer return values a little rude
Blake
of bytes encoded.
A2C_ERROR A2C_EncodeDer(PVOID pvData, PC_A2C_DESCRIPTOR pdesc, int
flags,
A2C_CONTEXT ** pcxt, PA2C_STREAM pstm);
* Returning "74" shoved in a A2C_ERROR doesn't seem particularly
polite. This is what I saw in my particular case.
* It breaks code that might check for errors. Like both:
if (err != A2C_ERROR_Success)
and
if (err)
won't work.
Blake
Paul Hoffman
>
> if (err != A2C_ERROR_Success)
>
> and
>
> if (err)
>
> won't work.
We designed A2C_ERROR to be expressive. Take a look at A2C_Error.h in
the runtime library. You'll see :
A2C_ERROR_Success=0,
A2C_ERROR_True = 1,
A2C_ERROR_False = 0,
A2C_ERROR_bufferOverRun = -2,
A2C_ERROR_outOfMemory = -3,
and a bunch more negative values.
That's why the meme we used in the sample code is "if err < 0".
Blake
> We designed A2C_ERROR to be expressive. Take a look at A2C_Error.h in
> the runtime library. You'll see :
> A2C_ERROR_Success=0,
> A2C_ERROR_True = 1,
> A2C_ERROR_False = 0,
> A2C_ERROR_bufferOverRun = -2,
> A2C_ERROR_outOfMemory = -3,
> and a bunch more negative values.
Indeed.
> That's why the meme we used in the sample code is "if err < 0".
My comments still stand, and are now expanded by:
* It is rude to check for negativity in an enum, and to intermix enums
and integers
* It is rude to use a return value for both status and for some other
integer like a length
Note that none of the things I have pointed out are technically
errors.
I've already crabbed to Jim about using +1 for True, and the SCODE-
like nature of this (negative values are errors, positive values are
warnings. Well, warnings or lengths apparently.)
I'm pretty much of the mindset that things like lengths get sent back
in parameters, and return values that can be "either an integer or a
status return value" creep me out.
Blake