-1

I am currently trying to build platform-specific implementations for a generic function, and I get weird compilation errors on the WIN32 version. This function is a simple one: it provides the path of the application's configuration file, and the Windows version should logically get it from a registry key.

The current implementation of that function looks like this:

#include <windows.h>

#include <memory>
#include <exception>
#include "../../common/bserrors.h"
#include "bsplatformsettings.h"
#include "bsplatformimpl.h"

std::string bsConfigFileAccessorImpl::ProvideFile() {
    HKEY    key = 0;
    DWORD   buffersz;
    std::string result;

    // Open registry key
    if (RegOpenKey(BSPS_FA_REGKEYGROUP, TEXT(BSPS_FA_REGKEYPATH), &key) != ERROR_SUCCESS) {
        throw bsError(bsErrcode::BSEC_INVALID_CONFIG_ACCESS, BSPS_FA_REGKEYPATH);
    }

    // Get the configuration file path
    if (RegQueryValueEx(key, TEXT(BSPS_FACONF_REGKEYNAME), NULL, REG_SZ, NULL, &buffersz) != ERROR_SUCCESS) {
        RegCloseKey(key);
        throw bsError(bsErrcode::BSEC_INVALID_CONFIG_ACCESS, BSPS_FACONF_REGKEYNAME);
    } else {
        char * buffer = new char[(size_t) buffersz];
        RegQueryValueEx(key, TEXT(BSPS_FACONF_REGKEYNAME), NULL, REG_SZ, (LPBYTE) buffer, &buffersz);

        result = std::string(buffer);
        delete(buffer);
    }

    RegCloseKey(key);
    return result;
}

However, when I am trying to compile that version, I get puzzling errors:

platform/win32/bsplatformimpl.cpp: In member function 'virtual std::string bs::bsConfigFileAccessorImpl::ProvideFile()':
platform/win32/bsplatformimpl.cpp:228:87: error: invalid conversion from 'int' to 'LPDWORD {aka long unsigned int*}' [-fpermissive]
if (RegQueryValueEx(key, TEXT(BSPS_FACONF_REGKEYNAME), NULL, REG_SZ, NULL, &buffersz) != ERROR_SUCCESS) {
                                                                            ^
platform/win32/bsplatformimpl.cpp:233:95: error: invalid conversion from 'int' to 'LPDWORD {aka long unsigned int*}' [-fpermissive]
RegQueryValueEx(key, TEXT(BSPS_FACONF_REGKEYNAME), NULL, REG_SZ, (LPBYTE) buffer, &buffersz);
                                                                                   ^

Looks like the DWORD definition presented at compilation time is not the one we would expect. However I don't define any custom DWORD definition anywhere and the DWORD definition in windows.h looks fine (aka. unsigned long int).

So where does that plain int come from? I'm very, very puzzled by these errors...

Does anyone get some ideas about what may be causing this and how to solve this?

The problematic port uses the following: Target system: windows XP 32 / Compiler: mingw32-gcc-g++ 4.8.1-4 / Compiler options: -pedantic-errors -Wall -Werror -Wextra -std=c++11

Thank you!!

MTBS devs
  • 3
  • 2
  • 'int' to 'LPDWORD {aka long unsigned int*}' says that you're trying to convert a integer type to a pointer. – Jepessen Nov 11 '14 at 12:51
  • Are you sure the code you show in the question is the code you actually try to compile? Do you have your own redefinition of `DWORD` in your own header files (or in a non-system library header file)? – Some programmer dude Nov 11 '14 at 12:58
  • I don't have any custom definition of DWORD anywhere. That's precisely what puzzles me. – MTBS devs Nov 11 '14 at 13:09

1 Answers1

4

It's complaining about the fourth argument, REG_SZ.

You're passing a value of the type you expect. But the function requires you to pass a buffer which receives the actual type.

lpType [out, optional]

A pointer to a variable that receives a code indicating the type of data stored in the specified value. For a list of the possible type codes, see Registry Value Types. The lpType parameter can be NULL if the type code is not required.

So you need something like:

DWORD dwActualType;

RegQueryValueEx(key, TEXT(BSPS_FACONF_REGKEYNAME), NULL, &dwActualType, (LPBYTE) buffer, &buffersz);
if (dwActualType == REG_SZ) ...
Community
  • 1
  • 1
Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Thank you! I was so focused on lpcbData because of the column rank in the error messages that I totally forgot to check lpType. The temporary correction I set on this term is now working nicely. Thank you very much. – MTBS devs Nov 11 '14 at 13:40
  • @MTBSdevs: Yes, that seemed weird. But when that parameter seemed ok, I checked the doc page, found a total of three parameters of type `LPDWORD`. Why the little `^` is in the wrong place is a mystery, I suppose it could be a "tabs vs spaces" issue, or else related to the expanded size of the several macros you are using (I count five on that line). – Ben Voigt Nov 11 '14 at 13:43