[PATCH] D107575: Ported test_errors.sh to Python
Mats Petersson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 5 11:22:22 PDT 2021
Leporacanthicus added a comment.
In D107575#2929026 <https://reviews.llvm.org/D107575#2929026>, @Meinersbur wrote:
> There seems to be a problem in how `import common` not finding `common.py` in a sibling directory.
>
> `vsnprintf` is named `_vsnprintf` by Microsoft. According to their docs <https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/1kt27hek(v=vs.120)>, it should also be available as `vsnprintf` with
>
> #include <stdio.h>
> #include <stdarg.h>
>
> but even Google test <https://github.com/google/googletest/blob/5b40153003d1a5ad7b8f40cffcd09434afda3428/googletest/src/gtest.cc#L121> uses
>
> #if GTEST_OS_WINDOWS
> # define vsnprintf _vsnprintf
> #endif // GTEST_OS_WINDOWS
That is only part of the problem - the code compiles without errors with `vsnprintf` in place - the Fortran compiler uses positional arguments (like `printf("%2$s, %1$s!\n", "World", "Hello")` that isn't supported by the normal MS printf implementation, you have to call `_vsprintf_p`.
Ivan is going to push a patch to fix this tomorrow (it's essentially the same idea, but `#define vsnprintf _vsnprintf_p`. Without that patch, messages come out with `$s` and `$d` in the error message, rather than the intended strings and numbers intended.
Me and Ivan spent some time figuring this out today. Why do compilers/libraries have to do these sort of things their own way? ;)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D107575/new/
https://reviews.llvm.org/D107575
More information about the llvm-commits
mailing list