On 3/15/07, Andrew Talbot Andrew.Talbot@talbotville.com wrote:
Changelog: FDI: Constify some variables.
diff -urN a/dlls/cabinet/cabinet_main.c b/dlls/cabinet/cabinet_main.c --- a/dlls/cabinet/cabinet_main.c 2007-03-15 17:31:18.000000000 +0000 +++ b/dlls/cabinet/cabinet_main.c 2007-03-15 20:16:45.000000000 +0000 @@ -86,7 +86,7 @@ HeapFree(GetProcessHeap(), 0, memory); }
-static INT_PTR fdi_open(char *pszFile, int oflag, int pmode) +static INT_PTR fdi_open(const char *pszFile, int oflag, int pmode) { HANDLE handle; DWORD dwAccess = 0; @@ -131,7 +131,7 @@ return 0; }
-static UINT fdi_write(INT_PTR hf, void *pv, UINT cb) +static UINT fdi_write(INT_PTR hf, const void *pv, UINT cb) { HANDLE handle = (HANDLE) hf; DWORD dwWritten; diff -urN a/dlls/msi/files.c b/dlls/msi/files.c --- a/dlls/msi/files.c 2007-02-26 17:43:07.000000000 +0000 +++ b/dlls/msi/files.c 2007-03-15 20:56:44.000000000 +0000 @@ -161,7 +161,7 @@ msi_free(pv); }
-static INT_PTR cabinet_open(char *pszFile, int oflag, int pmode) +static INT_PTR cabinet_open(const char *pszFile, int oflag, int pmode) { HANDLE handle; DWORD dwAccess = 0; @@ -202,7 +202,7 @@ return 0; }
-static UINT cabinet_write(INT_PTR hf, void *pv, UINT cb) +static UINT cabinet_write(INT_PTR hf, const void *pv, UINT cb) { HANDLE handle = (HANDLE) hf; DWORD dwWritten; diff -urN a/dlls/setupapi/setupcab.c b/dlls/setupapi/setupcab.c --- a/dlls/setupapi/setupcab.c 2006-11-10 17:26:30.000000000 +0000 +++ b/dlls/setupapi/setupcab.c 2007-03-15 20:45:39.000000000 +0000 @@ -113,7 +113,7 @@ HeapFree(GetProcessHeap(), 0, pv); }
-static INT_PTR sc_cb_open(char *pszFile, int oflag, int pmode) +static INT_PTR sc_cb_open(const char *pszFile, int oflag, int pmode) { DWORD creation = 0, sharing = 0; int ioflag = 0; @@ -204,7 +204,7 @@ return num_read; }
-static UINT sc_cb_write(INT_PTR hf, void *pv, UINT cb) +static UINT sc_cb_write(INT_PTR hf, const void *pv, UINT cb) { DWORD num_written; /* BOOL rv; */ diff -urN a/include/fdi.h b/include/fdi.h --- a/include/fdi.h 2006-05-23 13:49:04.000000000 +0100 +++ b/include/fdi.h 2007-03-15 19:53:38.000000000 +0000 @@ -205,14 +205,14 @@ typedef void (__cdecl *PFNFREE)(void *pv); #define FNFREE(fn) void __cdecl fn(void *pv)
-typedef INT_PTR (__cdecl *PFNOPEN) (char *pszFile, int oflag, int pmode); -#define FNOPEN(fn) INT_PTR __cdecl fn(char *pszFile, int oflag, int pmode) +typedef INT_PTR (__cdecl *PFNOPEN) (const char *pszFile, int oflag, int pmode); +#define FNOPEN(fn) INT_PTR __cdecl fn(const char *pszFile, int oflag, int pmode)
typedef UINT (__cdecl *PFNREAD) (INT_PTR hf, void *pv, UINT cb); #define FNREAD(fn) UINT __cdecl fn(INT_PTR hf, void *pv, UINT cb)
-typedef UINT (__cdecl *PFNWRITE)(INT_PTR hf, void *pv, UINT cb); -#define FNWRITE(fn) UINT __cdecl fn(INT_PTR hf, void *pv, UINT cb) +typedef UINT (__cdecl *PFNWRITE)(INT_PTR hf, const void *pv, UINT cb); +#define FNWRITE(fn) UINT __cdecl fn(INT_PTR hf, const void *pv, UINT cb)
typedef int (__cdecl *PFNCLOSE)(INT_PTR hf); #define FNCLOSE(fn) int __cdecl fn(INT_PTR hf)
Are you checking with the SDK to make sure these changes are legit? This isn't how the Windows SDK fdi.h has these defined.
James Hawkins wrote:
Are you checking with the SDK to make sure these changes are legit? This isn't how the Windows SDK fdi.h has these defined.
I ascertained that the function-pointer parameters of FDICreate() should have the same signatures as the corresponding low-level file functions (e.g., pfnopen should point to a function that takes and returns identical parameters to _open(), pfnwrite to _write(). Its pfnopen, is of type PFNOPEN and its pfnwrite of type PFNWRITE, so I constified those types to match the signatures of _open() and _write(), respectively, and altered the functions that were affected.
-- Andy.
On 3/15/07, Andrew Talbot Andrew.Talbot@talbotville.com wrote:
James Hawkins wrote:
Are you checking with the SDK to make sure these changes are legit? This isn't how the Windows SDK fdi.h has these defined.
I ascertained that the function-pointer parameters of FDICreate() should have the same signatures as the corresponding low-level file functions (e.g., pfnopen should point to a function that takes and returns identical parameters to _open(), pfnwrite to _write(). Its pfnopen, is of type PFNOPEN and its pfnwrite of type PFNWRITE, so I constified those types to match the signatures of _open() and _write(), respectively, and altered the functions that were affected.
That's not how it works. PFNOPEN, et al., has a specific definition that is similar to, but not the same as, the corresponding low-level file IO function. If you make a change to a public header, you need to check the same header in the SDK and make sure that the change is warranted. As it stands, this is wrong.
James Hawkins wrote:
That's not how it works. PFNOPEN, et al., has a specific definition that is similar to, but not the same as, the corresponding low-level file IO function. If you make a change to a public header, you need to check the same header in the SDK and make sure that the change is warranted. As it stands, this is wrong.
Hi James,
I accept your point, so the following is not an argument, but just for interest's sake I am posting this quote from "Microsoft FCI/FDI Library Description":
"The pfnopen, pfnread, pfnwrite, pfnclose, and pfnseek parameters should point to functions which perform file open, file read, file write, file close, and file seek operations respectively. These functions should accept parameters identical to those for the standard _open, _read, _write, _close, and _lseek functions, and should likewise have identical return codes."
I looked at the two function prototypes that I reviewed for these standard functions in our include/msvcrt/io.h and noted that they are constified.
But yes, I shall check the public header, in future.
Thanks,
-- Andy.