crypt32: Constify some variables (4 of 5) (Resend)

[Andrew Talbot]

Robert Shearman wrote:

> Andrew Talbot wrote:
>>  typedef BOOL (WINAPI *CryptDecodeObjectFunc)(DWORD, LPCSTR, const BYTE
>>  *,
>>   DWORD, DWORD, void *, DWORD *);
>>  typedef BOOL (WINAPI *CryptDecodeObjectExFunc)(DWORD, LPCSTR, const BYTE
>>  *,
>> - DWORD, DWORD, PCRYPT_DECODE_PARA, void *, DWORD *);
>> + DWORD, DWORD, const CRYPT_DECODE_PARA *, void *, DWORD *);
>>  
>>   
> 
> This declaration needs to match that of CryptDecodeObjectEx in wincrypt.h.
> 

Hi Rob,

I am just curious to know why. This was my reasoning:

CryptDecodeObjectEx - which I haven't touched - calls a selected local
function via this local function pointer. If the local function doesn't
alter the data to which a parameter points, is it not safe to constify the
local version of the parameter?

If there were an API function like so:

WINAPI INT StrpCmpA(LPSTR pszStrA, LPSTR pszStrB);

it would be OK to implement it with a helper function whose prototype was
something like:

static inline int strcmp(const char *s1, const char *s2);

as long as the promises of s1 and s2 were kept.

The only bit of memory-altering that I believe the PCRYPT_DECODE_PARA
pointer is associated with is this:

250         if (pDecodePara && pDecodePara->pfnAlloc)
251             *(BYTE **)pvStructInfo = pDecodePara->pfnAlloc(bytesNeeded);

but I don't think that this would preclude constifying the local parameter,
since it's only calling a function that allocates memory for a disconnected
structure.

-- Andy.