Incorrect format string determination from manifestly constant-evaluated contexts

[hubert-reinterpretcast]

Clang does not observe the surrounding manifestly constant-evaluated context when attempting -Wformat diagnostics.
In the case below, the program semantics uses the "%d\n" format string.
Clang diagnoses on the basis of the "%!\n" string instead.

https://godbolt.org/z/cGsM5Mjn5

Source (<stdin>)

#include <stdio.h>
#include <stdarg.h>

constexpr auto const_string() {
  if consteval {
    return "%d\n";
  }
  return "%!\n";
}

constexpr auto getvprintf [[gnu::format(__printf__, 1, 0)]](const char *format) {
  return [=](va_list vp) {
    return vprintf(format, vp);
  };
}

constexpr auto myvprintf = getvprintf(const_string());

void q(int x, ...) {
  va_list ap;
  va_start(ap, x);
  myvprintf(ap);
  va_end(ap);
}

int main(void) {
  q(0, 42);
}

Compiler invocation command

clang++ -fsyntax-only -Wall -Wextra -pedantic -std=c++2c -xc++ -

Actual compiler output

<stdin>:17:39: warning: invalid conversion specifier '!' [-Wformat-invalid-specifier]
   17 | constexpr auto myvprintf = getvprintf(const_string());
      |                                       ^~~~~~~~~~~~~~
<stdin>:8:12: note: format string is defined here
    8 |   return "%!\n";
      |           ~^
1 warning generated.

Expected compiler output

(No warning)

Compiler version info (clang++ -v)

clang version 21.0.0git (https://github.com/llvm/llvm-project.git 77f0708b9d4feee8b8a67a5f571be741be4e26af)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/wandbox/clang-head/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/13
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/14
Candidate multilib: .;@m64
Selected multilib: .;@m64

[apple-fcloutier]

FWIW, it's a known issue (to me at least) that format(_, _, 0) should be diagnosed on functions that don't accept a va_list because there is nothing that the analysis can do to tie your use of variadic arguments to a format string later on. I am not aware of any way that you can get clang to diagnose a format issue on q(0, "hello"), and the key enabler to that escape is format(_, _, 0).

Do you think that there is a way to reproduce the same problem without using format(_, _, 0) on a function that doesn't take a va_list? If not, I'm tempted to say the issue will "self-resolve" when somebody does something about it.

[hubert-reinterpretcast]

FWIW, it's a known issue (to me at least) that format(_, _, 0) should be diagnosed on functions that don't accept a va_list because there is nothing that the analysis can do to tie your use of variadic arguments to a format string later on.

Technically, there's nothing to tie the arguments to a format string for any use of format(_, _, 0). There is no requirement that there is a unique va_list argument for the function (e.g., there may be more than one).

format(_, _, 0) is basically limited to checking that the conversion specifications are valid.

[apple-fcloutier]

Technically, there's nothing to tie the arguments to a format string for any use of format(_, _, 0). There is no requirement that there is a unique va_list argument for the function (e.g., there may be more than one).

That's true, but my opinion of an ideal world is that we would have something to tie the va_list to a format string, like format(vprintf, format-idx, va-list-idx) instead of keeping it free-floating. Also worth saying that I'm aware of exactly one code base that uses functions that have multiple __attribute__((format)) (https://www.kernel.org/pub/linux/utils/util-linux/v2.41/), and of none that has format functions taking two va_lists, counts including my employer's private code bases.

format(_, _, 0) is basically limited to checking that the conversion specifications are valid.

From my security-centric perspective (I am a security engineer first and a compiler person by accident), this use of format(_, _, 0) is less interesting than letting the compiler know that a format string is forwarded from somewhere else for -Wformat-nonliteral enforcement. If you don't have the arguments at the site where the string is being checked, you're missing out on almost all of the security-relevant things you should be looking for.

[apple-fcloutier]

Another shape of essentially the same diagnostic would be "format string was not verified against format arguments", and this would necessarily trigger for a format(_, _, 0) function that doesn't take a va_list itself.

[apple-fcloutier]

This has the same bug and sidesteps my opinions about whether format(_, _, 0) is good: https://godbolt.org/z/zTfGfGvKj

__attribute__((format(printf, 1, 2)))
int printf(const char *, ...);

constexpr const char *consteval_str() {
  if consteval {
    return "%s";
  } else {
    return "%d"; // expected-note 2{{format string is defined here}}
  }
}

constexpr const char *consteval_str_global = consteval_str();

void test_consteval_str() {
  printf(consteval_str(), 789);
  printf(consteval_str_global, "hello");
}

There should be no warnings, but printf(consteval_str_global, "hello") trips.