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.
