Re: [Plib-devel] Re: WIN32 USB joystick name problem - possible fix [was: Joystick documentation problem]

[Curtis L. O. <cu...@me...>]

Sebastian Ude writes:
> By the way: I copied the code as seen on MSDN into my mail - and the wrong
> max-name-length was not the only strange thing I found in it now that I had
> a closer look onto the code.
> 
> For example, the third argument to the RegQueryValueEx () is a "unsigned
> char *" (LPBYTE) pointer. At the top of the function, the programmer
> defines an array of unsigned chars (UCHAR) called "szOEMKey".
> 
> Now, when calling RegQueryValueEx (), whoever wrote the MSDN document takes
> the address of the array, thus gets a "unsigned char **" pointer which he
> casts back into an "unsigned char *" (LPBYTE) pointer in order to pass it
> to the function.
> 
> unsigned char szOEMKey[256];
> 
> /* ... */
> 
> RegQueryValueEx ( /* ... */ (unsigned char *) &szOEMKey /* ... */ ) ;
> 
> 
> The same thing is done another time in the function. What the heck is the
> idea behind this ? I hard a hard time thinking if there could be a good
> reason to take address of the array of unsigned chars (unsigned char **)
> and cast it back into a pointer-to-unsigned-char (unsigned char *), but I
> could not find one.
> 
> That brings up a scary idea: Perhaps the Microsoft employee had not too
> much knowledge about pointers and arrays in C, just saw that the function
> requires a pointer as it third argument and hence took the address of the
> array. Of course, the compiler complained about the programmer passing
> "unsigned char **" to a function expecting "unsigned char *", and in
> good-old Microsoft fashion he placed a cast to make the compiler shut up
> ..

Looks like it might be a literal translation from the original
Fortran.

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org