Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ExpandEnvAndSearchPath not /permissive- clean #26

Closed
zx64 opened this issue May 11, 2019 · 3 comments
Closed

ExpandEnvAndSearchPath not /permissive- clean #26

zx64 opened this issue May 11, 2019 · 3 comments
Labels
bug Something isn't working

Comments

@zx64
Copy link

zx64 commented May 11, 2019

Tested against 4361351

Test file (in root of repo for simplicity)

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <cstdint> // for SIZE_MAX in resource.h
#include "include/wil/win32_helpers.h"
int main() {}
> cl testwil.cpp /W4 /WX /permissive-
Microsoft (R) C/C++ Optimizing Compiler Version 19.20.27508.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

testwil.cpp
[...]/include/wil/win32_helpers.h(190): error C2760: syntax error: unexpected token 'identifier', expected ';'
[...]/include/wil/win32_helpers.h(190): error C7510: 'unique_cotaskmem_string': use of dependent type name must be prefixed with 'typename'

That appears to be the only blocker to making that header compile with /permissive-.

@dunhor dunhor added the bug Something isn't working label May 13, 2019
@dunhor
Copy link
Member

dunhor commented May 13, 2019

Looks like win32_helpers.h under-includes its dependencies. Objbase.h should be included before resource.h. In the meantime, this can be worked around by either including this file before win32_helpers.h or by not defining WIN32_LEAN_AND_MEAN

@jonwis
Copy link
Member

jonwis commented Jun 29, 2019

The environment string code appears to use unique_cotaskmemstring_ptr as its default output type. Is there a good reason to use that vs wil::unique_process_heap_string_ptr or a wistd::unique_ptr<wchar_t> instance? Changing the default in the OS repo might hit compilation errors as a result of code like:

wil::unique_cotaskmemstring_ptr evar = ExpandEnvironmentStringsW(L"%muffin%");

jonwis pushed a commit that referenced this issue Jun 29, 2019
A better change might be to switch away from
unique_cotaskmemstring_ptr as the default output
type for these methods.
jonwis added a commit that referenced this issue Jul 6, 2019
…nt (#64)

* Fix #62, add FreeEnvironmentStrings helpers

* Resolves #63 by adding `= void` to the various generic _ptr resource managers.

* Initial workaround for #26

A better change might be to switch away from
unique_cotaskmemstring_ptr as the default output
type for these methods.

* Add test to validate and lock in expectations in #61

* Oops, unreferenced variable!

* PR feedback
@jonwis
Copy link
Member

jonwis commented Jul 7, 2019

Should be fixed now.

@jonwis jonwis closed this as completed Jul 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants