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

[Robert Shearman]

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.

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.