On Tue, 14 Oct 2025, Osama Abdelkader wrote: > + const char *func_name = > format_types[info->format_type].name; > + /* Suggest the v-variant function name. Handle both > + "printf" and "gnu_printf" style names. */ > + const char *v_func_name = func_name; > + if (strncmp (func_name, "gnu_", 4) == 0) > + v_func_name = "vprintf"; > + else if (strncmp (func_name, "ms_", 3) == 0) > + v_func_name = "vprintf"; > + else if (strncmp (func_name, "printf", 6) == 0) > + v_func_name = "vprintf"; > + else if (strncmp (func_name, "scanf", 5) == 0) > + v_func_name = "vscanf"; > + else if (strncmp (func_name, "strftime", 8) == 0) > + v_func_name = "vstrftime"; > + else > + v_func_name = func_name; /* Fallback */ > + > + warning_at (param_loc, OPT_Wformat_, > + "passing %<va_list%> as a variadic argument; " > + "did you mean to use %<%s%> instead?", > + v_func_name);
I don't think this attempt to compute a new function name from the format attribute is particularly optimal. If someone is using snprintf, maybe they actually meant vsnprintf (not vprintf), for example. Often you have an actual decl for the function being called, but in general you don't, or it may be some custom function from the user's program with a format attribute for which you don't know what if any v* equivalent there is. You could make the message more generic rather than trying to say exactly what function the user might have meant, or that could be supplemented by a table of mappings (printf -> vprintf, snprintf -> vsnprintf, etc.) for the common standard functions. > +/* Test that user-defined types with "va_list" in the name don't trigger > false positives */ I think it's also a good idea to test that void* doesn't generate false positives even when that's the definition of va_list (the default one used by GCC for targets that don't define the hook otherwise). (Or if it does, then is_va_list_type is too permissive.) -- Joseph S. Myers [email protected]
