DCL11-C. Understand the type issues associated with variadic functions

The example here seems rather contrived. A mismatch between printf format specifications and arguments passed is a widely known problem and really does not have anything to do with the point of this rule.

It seems to me that a better example would be one that intermixes arguments of clearly different widths (int with long long, float with double) so that a correcting ordered, but with incorrect type indicators, format string would result in extremely unexpected results.

Lastly, it is unclear to me that alignment errors are possible. A variadic function call results in the "..." arguments being put through default promotions, regardless of their original widths (char and short -> int). In the end, the only two possible alignments are word or double-word (as the examples I gave above). On no architecture will a word boundary cause an alignment error. And only on rare architectures must double-word values be aligned on a double-word boundary (usually word boundaries are sufficient).

All these details aside, my observation is that this example does not demonstrate your rule's title. 

100% of C programmers use printf(), but far less use variadic functions of their own creation, and I believe that making a separate printf-type page would make these rules a lot more approachable.

The rules are essentially the same, of course, but removing the va_arg() business to a separate rule means that one can focus on conveying the alignment and promotion rules in a much more familiar context.

long long a = 1L;
char msg[] = "Default message";
/* ... */
printf("%lld %s", a, msg);
 
sizeof(msg) will be 17 but not 128  

long long a = 1L - Software Optimization Guide for AMD64 Processors

I recall that Fortify SCA can also detect violations of this rule. Can someone double check and add to auto-detection section if appropriate?

This is perhaps an issue specific to the macro NULL rather than to variadic functions but I haven't been able to find a rule that deals with the former.

Another cause of undefined behavior is using the NULL macro as an argument to a variadic functions such as printf() or execl() where a pointer value is expected. For example, the following function calls will have undefined behavior when sizeof(NULL) != sizeof(void*) as may be the case in LP64 when NULL defined to be of type int:

printf("%p %d\n", NULL, 1);
execl("ls", "*.text", NULL);

To ensure that the calls behave correctly the code must be written like so:

printf("%p %d\n", (void*)0, 1);
execl("ls", "*.text", (char*)0);

I agree: neither NULL or (char*)0 is a valid argument for %s or any other conversion specification that expects a pointer to an object in memory (e.g., %n).

I'm sorry, but I don't understand this NULL example. I know it's undefined (null pointer is not a string, and printing nothing could do anything), but the explanation just doesn't make sense. Yes, null pointer is not guaranteed to be ((void *) 0), but in this case it doesn't matter. Let's assume that we use a crazy platform where NULL is ((_Bool) 0) (by the way, C specification guarantes that any constant zero is null pointer), and the code is ran on it. After this strange boolean null is assigned to char *, the value is a pointer (pointer that would magically change sizes depending on whether it stores null pointer or not wouldn't make sense, would it?).

I made a small code sample in order to show null pointer being boolean false. If you run it in compiler that understands null pointer is any constant zero (like Clang), you will notice that var has the same size as void *. The NULL is called NULLISH, because some compilers disallow redefining NULL.

#include <stdio.h>
#define NULLISH ((_Bool) 0)
int main(void) {
    char *var = NULLISH;
    printf("%d %d %d\n", (int) sizeof NULLISH, (int) sizeof var, (int) sizeof(void *));
    return 0;
}

On my computer, this code returns 1 8 8, which makes sense. I believe the guideline should mention something else instead. I think that something like GTK+ variadic argument lists (real code) is a good idea for an example - in GTK, some functions expect list of strings that ends with null pointer. If the platform has null declared as integer, and size of pointers is different to size of integers, things break. For example, I propose following code sample as example, containing a big trap (if NULL is not declared as pointer, things are broken).

#include <stdio.h>
#include <stdarg.h>
void put_multiple(const char *argument, ...) {
    va_list args;
    va_start(args, argument);
    while (argument) {
        puts(argument);
        argument = va_arg(args, const char *);
    }
    va_end(args);
}
int main(void) {
    put_multiple("Line 1", "Line 2", "Line 3", NULL);
    return 0;
}

Imagine that NULL is declared as boolean false (completely valid, even if it's silly). You would get random explosions that would be hard to debug just because _Bool is not const char *.

C11 7.19p3 says:

The macros are
  NULL
which expands to an implementation-defined null pointer constant;

This text is unchanged since C99. (does C90 say something different?)

Since the standard says nothing about NULL being an integer constant, I wonder if the NULL NCCE is truly noncompliant?

C17 is the final version of C11, including all resolved defect reports and is the version of the standard you should be referencing.