[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