[cfe-dev] Relaxing format specifier checks

[Hubert Tong via cfe-dev]

On Thu, May 17, 2018 at 10:52 AM, James Y Knight <jyknight at google.com>
wrote:

> This is a convincing point, but the reasoning here is somewhat different,
> since it's dealing with pointer-types, and then an actual
> pointer-dereference of the incorrect type. That's certainly a bad idea -- I
> agree it'd be quite unwise to change the behavior when dealing with
> pointers, either in the scanf specifiers or for the expected pointee-type
> of %n in printf.
>
> I think the question at hand is whether a type-mismatch of the value
> itself is a problem you should be worried about. E.g., calling
> "va_arg(long)" when passing a value of type int to the call, where int and
> long are "the same".
>
So, platform-specific knowledge can cut both ways in this space. Suppose
that on some platform, the ellipsis on a function simply becomes an extra void
* argument, the space for the variable arguments are created as a local
structure with the arguments (with no packing or surprising alignment
rules), and va_arg is implemented to cast to a pointer to the type provided
after adjusting the current pointer in the va_list. Modifying the Clang AST
to make these aspects explicit will create the TBAA information. Assuming
that on this platform the void */char * compatibility under va_arg is taken
into account by TBAA, the modification of the Clang AST should be safe.
Maybe the platform guarantees that users can do so at the source level. The
question becomes one of how "int" and "long" should be determined to be
"the same" or not. It looks like a property of the target to me. My other
note mentions that it is possible for different registers to be used for
passing types that are indistinguishable when in memory.


>
>
> On Thu, May 17, 2018 at 1:16 AM Hubert Tong via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Fri, May 11, 2018 at 7:26 PM, Shoaib Meenai via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> Of course, we should also ensure that the optimizer doesn't do anything
>>> surprising when there's a type mismatch between the specifier and the
>>> argument but both types have the same size and alignment (i.e., the case
>>> where the relaxed format warning won't fire), both now and in the future.
>>>
>> The "contract" for the format string and the corresponding argument is as
>> described elsewhere in the thread, and it is rather more interesting for
>> scanf than not. GCC's implementation technology is apparently able to
>> optimize (at -O2 and up, at least when targeting powerpc64le-linux-gnu) the
>> check feeding the abort() in the following to not observe the write
>> performed in the ersatz scanf():
>> #include <stdarg.h>
>> void abort(void);
>> int strcmp(const char *, const char *);
>>
>> typedef int Type;
>> typedef long NType;
>>
>> int myvscanf(const char *const fmt, va_list ap) {
>>   if (strcmp(fmt, "%ld") != 0) { return 0; }
>>
>>   NType *const p = va_arg(ap, NType *);
>>   *p = 42;
>>   return 1;
>> }
>>
>> __attribute__((__format__(__scanf__, 2, 3)))
>> __attribute__((__noinline__, __noclone__))
>> void updateStatusFromPipe(Type *statusp, const char *const fmt, ...) {
>>   va_list ap;
>>   va_start(ap, fmt);
>>   int ret = 0;
>>   if (*statusp == 0) {
>>     ret = myvscanf(fmt, ap);
>>   }
>>   va_end(ap);
>>   if (ret >= 1 && *statusp != 0) abort();
>> }
>>
>> int main(void) {
>>   Type status = 0;
>>   updateStatusFromPipe(&status, "%ld", &status);
>> }
>>
>> The "now or in the future" sounds like needing to do "worse" or "better"
>> than what GCC is doing to avoid "anything surprising", because "on par"
>> with GCC fits the bill for something "surprising". Which is to say that, in
>> my opinion, there is no avoiding "something surprising" "in the future" on
>> code that the proposed relaxation is letting slip through.
>>
>> TL;DR: Please don't change the default.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180517/94d2a899/attachment.html>