No validation on number of arguments? #492
Comments
|
Unfortunately compile-time checks are not supported although there are some tricks in #62 for printf formatting. As for checking the arguments, the library follows Python's |
|
Have you considered doing something with UDLs? Like: |
|
@foonathan Unfortunately, UDLs don't help here because there is no way to get type-system constants out of a #include <type_traits>
constexpr auto operator""_size(char const*, std::size_t size) {
return std::integral_constant<std::size_t, size>{};
// ^~~~
// error: non-type template argument is not a constant expression
}
int main() {
static_assert("hello"_size.value == 5, "");
}The issue is that This could be solved if future standards allow overloading on the |
|
There's a UDL version that takes the chars at non-type template argument... but not for string literals, damn it, you're right. |
|
Compile-time format string checks are now available: http://zverovich.net/2017/11/05/compile-time-format-strings.html |
|
@vitaut but that does not solve mentioned issue right? |
|
There is a validation in a sense that you cannot refer to nonexisting argument. Passing extra ones is OK as explained earlier. |
|
Yes, and I dont see good reason why. Just today I had an issue where I passed extra one.. Can you please clarify whether this is concious decision or a limitation of the language? Because if you were able to achieve checking of {1} then I would hope that checking of argument could would be possible as well? :) |
This is a conscious decision. You can think of it as having unused arguments in a function - there are valid use cases for that. If we had a way of reporting warnings, it could be an opt-in warning as in |
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any error (either runtime or compile-time) [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any error (either runtime or compile-time) [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
Unfortunately, {fmt} allows passing too many arguments to a format call
without raising any runtime or compile-time error [1].
As this is a common source of bugs since we started migrating to {fmt},
this commit adds some custom logic to validate the number of
replacement fields in format strings in addition to {fmt}'s own checks.
[1] fmtlib/fmt#492
|
It might be reasonable to provide a separate overload that performs this check, or perhaps even allowing the user to specify which checks he wants with a bitflag mechanism |
|
Recently I've adapted my company's internal logging class to Oh god, I've just discovered the same is allowed for Update. |
|
There are no plans to make this configurable but you can implement such a check (at least for simple cases because in general this feature may not be implementable) in your logging function. |
Oh god indeed.
Can you elaborate what those cases are? |
|
IMO, if you want good error messages for fmt you need to ask the compiler implementors (GCC and Clang) to create support for format string warnings in the compilers, just like printf format string checking is implemented by compilers not by the C runtime. Since std::format exists now, it should definitely be something on their radar as a new attribute for example. It's an amazing feat that fmt was able to generate the compile-time support that it has so far, and I tip my hat for sure, but there's just no way to get really useful, clear, concise, and warnings vs. errors, etc. for checking fmt strings without compiler support. |
|
This can be solved by providing a compile-time diagnostic reporting function in C++. Hardcoding format string parsing in the compiler doesn't make much sense and isn't even possible for UDTs. |
|
Sure that would be good too, especially if it were possible to allow the user to choose whether the diagnostic was considered fatal or not (-Werror). But, we definitely want the ability to detect and notify the user if they provided TOO MANY arguments for the format string, not just too few arguments. At least, we want the option to do that. And it would be very nice if we could attach the checking attributes to the declaration (as we can with attributes), not the invocation as we do today, so we don't need to litter the code with FMT_STRING macros. |
|
|
Loosely based on: fmtlib/fmt#1294 See also: fmtlib/fmt#492
There doesn't seem to be any validation on the number of arguments passed matching the number in the format, at least in my usage of the writer api. Since fmtlib was advertised as a "safe" alternative to printf(), I guess I assumed that it would implement an equivalent of the compile-time checking of
-Wformat, which does warn about argument count mismatches. Am I doing something wrong, or just expecting too much of fmtlib?The text was updated successfully, but these errors were encountered: