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.