I want to write a function to print characters on an LCD in a similar way that printf/sprintf does using formatting strings.
You may use sprintf function to format the strings and print to LCD.
char buffer[50];
int a = 10, b = 20, c;
c = a + b;
sprintf(buffer, "Sum of %d and %d is %d", a, b, c);
Now the buffer will have the formatted strings
You could write a variadic function and pass the parameters on to vsnprintf():
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
void display(int foo, int bar, char const *format, ...)
{
va_list arglist;
va_start(arglist, format);
int length = vsnprintf(NULL, 0, format, arglist);
char *buffer = malloc(length * sizeof *buffer);
vsnprintf(buffer, length, format, arglist);
va_end(arglist);
puts(buffer);
free(buffer);
}
int main(void)
{
display(42, 13, "%s %d %f", "Hello", 99, 100.13);
}
This answer takes the best parts of all of the other answers and puts them into one. I consider it to be the best way to do this given all factors, and will explain in more detail after presenting the example.
Summary:
Here's a full example, including with basic error checking in the function. Here I create a printf-like function called lcd_printf(), which works exactly like printf(). It uses vsnprintf() to store a formatted string into a statically-allocated buffer. You can then send this buffer to the LCD display at the location indicated by my comment.
Example Code:
lcd_print.h:
// For info on the gcc "format" attribute, read here under the section titled
// "format (archetype, string-index, first-to-check)":
// https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes.
int lcd_printf(const char * format, ...) __attribute__((format(printf, 1, 2)));
lcd_print.c:
#include "lcd_print.h"
#include <stdarg.h> // for variable args: va_list
#include <stdio.h> // for vsnprintf()
#include <limits.h> // for INT_MIN
// `printf`-like function to print to the LCD display.
// Returns the number of chars printed, or a negative number in the event of an error.
// Error Return codes:
// 1. INT_MIN if vsnprintf encoding error, OR
// 2. negative of the number of chars it *would have printed* had the buffer been large enough (ie: buffer would
// have needed to be the absolute value of this size + 1 for null terminator)
int lcd_printf(const char * format, ...)
{
int return_code;
// Formatted string buffer: make as long as you need it to be to hold the longest string you'd ever want
// to print + null terminator
char formatted_str[128];
va_list arglist;
va_start(arglist, format);
// Produce the formatted string; see vsnprintf documentation: http://www.cplusplus.com/reference/cstdio/vsnprintf/
int num_chars_to_print = vsnprintf(formatted_str, sizeof(formatted_str), format, arglist);
va_end(arglist);
if (num_chars_to_print < 0)
{
// Encoding error
return_code = INT_MIN;
return return_code; // exit early
}
else if (num_chars_to_print >= sizeof(formatted_str))
{
// formatted_str buffer not long enough
return_code = -num_chars_to_print;
// Do NOT return here; rather, continue and print what we can
}
else
{
// No error
return_code = num_chars_to_print;
}
// Now do whatever is required to send the formatted_str buffer to the LCD display here.
return return_code;
}
main.c:
#include "lcd_print.h"
int main(void)
{
int num1 = 7;
int num2 = -1000;
unsigned int num3 = 0x812A;
lcd_printf("my 3 numbers are %i, %i, 0x%4X\n", num1, num2, num3);
return 0;
}
Explanation & comparison to alternate approaches:
#Harikrishnan points out you should use sprintf(). This is on the right track, and is a valid, but less versatile and complete approach. Creating a new variadic function which uses vsnprintf(), as #Swordfish and I have done, is better.
#Swordfish does a fantastic demonstration of the proper usage of vsnprintf() in order to create your own printf()-like variadic function. His example (aside from lacking error handling) is the perfect template for a custom printf()-like implementation which relies on dynamic memory allocation. His first call to vsnprintf(), with a NULL destination buffer, does nothing more than determine how many bytes he needs to allocate for the formatted string (this is an ingenious and commonly-used trick for this application), and his second call to vsnprintf() actually creates the formatted string. For non-real-time applications which also have large amounts of RAM (ex: PC applications) this is the perfect approach. However, for microcontrollers I strongly recommend against it because:
It is non-deterministic. Calling free() can take different (and indeterminable before-hand) amounts of time to complete each time you call it. This is because the heap memory becomes fragmented over time. This means this approach is not good for real-time systems.
For more information about various heap implementations for malloc() and free(), review the 5 heap implementations, for example, described by FreeRTOS here: https://www.freertos.org/a00111.html. Search this page for "deterministic".
It is unbounded. It will attempt to malloc() ANY amount of memory required for the formatted string. This is bad, as it is more prone to stack-overflow. On safety-critical microcontroller-based systems, stack overflow needs to be strongly guarded against. A preferred approach is to use statically-allocated memory like I have done, with a fixed maximum size.
Additionally, it is lacking the GCC "format" attribute, which is a nice touch (more on this below).
#P__J__ mentions the GCC "format" attribute. My example uses this as well.
If using the GCC compiler, or any other compiler which has something similar, this is highly recommended to add to any custom printf()-like function you make.
The GCC documentation, under the section called format (archetype, string-index, first-to-check), states:
The format attribute specifies that a function takes printf, scanf, strftime or strfmon style arguments that should be type-checked against a format string.
In other words, it provides extra protections and checks to your custom printf()-like function at compile time. This is good.
For our case, simply use printf as the archetype, and a number for the string-index and first-to-check parameters.
The parameter string-index specifies which argument is the format string argument (starting from 1), while first-to-check is the number of the first argument to check against the format string.
Since non-static C++ methods have an implicit this argument, the arguments of such methods should be counted from two, not one, when giving values for string-index and first-to-check.
In other words, here are some valid example usages for this attribute applied to printf()-like function prototypes:
In C:
int lcd_printf(const char * format, ...) __attribute__((format(printf, 1, 2))); // 1 is the format-string index (1-based), and 2 is the variadic argument (`...`) index (1-based)
int lcd_printf(my_type my_var, const char * format, ...) __attribute__((format(printf, 2, 3))); // 2 is the format-string index (1-based), and 3 is the variadic argument (`...`) index (1-based)
int lcd_printf(my_type my_var, my_type my_var2, const char * format, my_type my_var3, ...) __attribute__((format(printf, 3, 5))); // 3 is the format-string index (1-based), and 5 is the variadic argument (`...`) index (1-based)
In C++:
int lcd_printf(const char * format, ...) __attribute__((format(printf, 2, 3))); // 2 is the format-string index (2-based), and 3 is the variadic argument (`...`) index (2-based)
int lcd_printf(my_type my_var, const char * format, ...) __attribute__((format(printf, 3, 4))); // 3 is the format-string index (2-based), and 4 is the variadic argument (`...`) index (2-based)
int lcd_printf(my_type my_var, my_type my_var2, const char * format, my_type my_var3, ...) __attribute__((format(printf, 4, 6))); // 4 is the format-string index (2-based), and 6 is the variadic argument (`...`) index (2-based)
Read more in my other answer here: How should I properly use __attribute__ ((format (printf, x, y))) inside a class method in C++?.
So, putting everything above together, you get the ideal solution for microcontrollers, which I've presented above.
as most commnly used arm compiler is gcc I will only focus on this one. The compiler can check the format & the prameters same as printf does
__attribute__ ((format (printf...
From the gcc documentation
format (archetype, string-index, first-to-check)
The format attribute specifies that a function takes printf, scanf, strftime or strfmon style arguments which should be
type-checked against a format string. For example, the declaration:
extern int
my_printf (void *my_object, const char *my_format, ...)
__attribute__ ((format (printf, 2, 3)));
causes the compiler to check the arguments in calls to my_printf for consistency with the printf style format string argument
my_format.
The parameter archetype determines how the format string is interpreted, and should be printf, scanf, strftime or strfmon. (You
can also use printf, scanf, strftime or strfmon.) The
parameter string-index specifies which argument is the format string
argument (starting from 1), while first-to-check is the number of the
first argument to check against the format string. For functions where
the arguments are not available to be checked (such as vprintf),
specify the third parameter as zero. In this case the compiler only
checks the format string for consistency. For strftime formats, the
third parameter is required to be zero.
In the example above, the format string (my_format) is the second argument of the function my_print, and the arguments to check start
with the third argument, so the correct parameters for the format
attribute are 2 and 3.
The format attribute allows you to identify your own functions which take format strings as arguments, so that GCC can check the
calls to these functions for errors. The compiler always (unless
-ffreestanding is used) checks formats for the standard library functions printf, fprintf, sprintf, scanf, fscanf, sscanf, strftime,
vprintf, vfprintf and vsprintf whenever such warnings are requested
(using -Wformat), so there is no need to modify the header file
stdio.h. In C99 mode, the functions snprintf, vsnprintf, vscanf,
vfscanf and vsscanf are also checked. Except in strictly conforming C
standard modes, the X/Open function strfmon is also checked as are
printf_unlocked and fprintf_unlocked. See Options Controlling C
Dialect. format_arg (string-index)
The format_arg attribute specifies that a function takes a format string for a printf, scanf, strftime or strfmon style function and
modifies it (for example, to translate it into another language), so
the result can be passed to a printf, scanf, strftime or strfmon style
function (with the remaining arguments to the format function the same
as they would have been for the unmodified string). For example, the
declaration:
extern char *
my_dgettext (char *my_domain, const char *my_format)
__attribute__ ((format_arg (2)));
causes the compiler to check the arguments in calls to a printf, scanf, strftime or strfmon type function, whose format string argument
is a call to the my_dgettext function, for consistency with the format
string argument my_format. If the format_arg attribute had not been
specified, all the compiler could tell in such calls to format
functions would be that the format string argument is not constant;
this would generate a warning when -Wformat-nonliteral is used, but
the calls could not be checked without the attribute.
Related
Question
Is there a way to pass many arguments to MyPrint() below using some kind of array containing a list of pointers to strings that va_start() understands before calling vsnprintf()?
Example of a format string specifier. It would be nice to create an array of the corresponding values and pass that to MyPrint() rather than individually passing each argument. I don't know if it's possible for va_start() to understand it. :(
"[0x%llX][%u] %s --- A=%llu (0x%llX) B=%llu (0x%llX) C=%llu (0x%llX) X=%llu (0x%llX) Y=%llu (0x%llX) Z=%llu (0x%llX)"
Details
MyPrint() calls vsnprintf() which prints a formatted list of arguments to a character array. The declaration for vsnprintf() is shown below:
int vsnprintf(char *arr, size_t len, const wchar_t *format, va_list args);
Parameters
arr: Pointer to the character array where output is to be printed
len: Maximum number of characters that can be written to the array
format: Format in which the output will be printed
args: Pointer to the list of arguments to be printed
Demo
#include <stdio.h>
#include <stdarg.h>
int MyPrint(char* buffer, int bufferSize, const char *format, ...)
{
int len = 0;
va_list arguments;
va_start(arguments, format);
len = vsnprintf(buffer, bufferSize, format, arguments);
va_end(arguments);
return len;
}
int main()
{
char buffer[256];
MyPrint(buffer, 256, "%s %s","Hello","World");
printf("%s",buffer);
return 0;
}
Is there a way to pass many arguments to MyPrint() below using some kind of array containing a list of pointers to strings that va_start() understands before calling vsnprintf()?
The only defined ways to initialize a va_list, such as vsnprintf() requires as a parameter, are
via the va_start() macro, operating in the context of a variadic function to form a va_list from the function's variadic arguments, and
via the va_copy() macro, to make a copy of another va_list.
There is no mechanism in standard C to form a va_list from the elements of an array, except by passing them all, individually, to a variadic function.
Variadic functions are about coding flexibility, not data flexibility. If you want a function that handles arrays of data, then write a (non-variadic) one that does so.
Whenever you consider writing your own varargs function, smack yourself in the head and repeat the mantra: "varargs is not the answer". Only if you still have varargs in your head after a few iterations of that should you should consider actually investigating that option.
I built a custom logging function that takes in a "log level" and string. A user would specify the log level associated with the message (i.e. error, warning, trace, etc.). The logging function would only print the message to the console depending on the current log level configured.
int global_log_level = INFO;
void logger(int msg_log_level, char * msg)
{
if(msg_log_level >= global_log_level )
{
printf("Log Level = %u: %s", msg_log_level, msg);
}
}
Ideally, I want to feed formatted strings to this function.
logger(LOG_LEVEL_ERROR, "Error of %u occurred\n", error_code);
However, by adding this "wrapping" logic, I'm unable to input formatted message. Instead, I have to write the message to a temporary string and then feed that into the function.
char temp[512];
sprintf("Error of %u occurred\n", error_code);
logger(LOG_LEVEL_ERROR, temp);
Is there a way to implement the logger function such that I don't need to have the user create a temporary string themselves?
This is question 15.5 on the C FAQ list.
You want vprintf, which lets you write your own printf-like function logger, but where you can pass the actual format string and arguments off to vprintf to do the work. The trick is that you need to construct a special va_arg type to "point to" the variable-length argument list. It looks like this:
#include <stdarg.h>
int global_log_level = INFO;
void logger(int msg_log_level, char * msg, ...)
{
va_list argp;
va_start(argp, msg);
if(msg_log_level >= global_log_level )
{
printf("Log Level = %u: ", msg_log_level);
vprintf(msg, argp);
}
va_end(argp);
}
As an addition to the #SteveSummit answer many compilers have special pragmas or attributes to indicate that the function is "printf-like". It allows the compiler to check parameters compile-time same as it is done when using printf
Example gcc :
format (archetype, string-index, first-to-check)
The format attribute specifies that a function takes printf, scanf,
strftime or strfmon style arguments which should be type-checked
against a format string. For example, the declaration:
extern int
my_printf (void *my_object, const char *my_format, ...)
__attribute__ ((format (printf, 2, 3)));
causes the compiler to check the arguments in calls to my_printf for consistency with the printf style format string argument
my_format.
The parameter archetype determines how the format string is interpreted, and should be printf, scanf, strftime or strfmon. (You
can also use __printf__, __scanf__, __strftime__ or __strfmon__.) The
parameter string-index specifies which argument is the format string
argument (starting from 1), while first-to-check is the number of the
first argument to check against the format string. For functions where
the arguments are not available to be checked (such as vprintf),
specify the third parameter as zero. In this case the compiler only
checks the format string for consistency. For strftime formats, the
third parameter is required to be zero.
In the example above, the format string (my_format) is the second argument of the function my_print, and the arguments to check start
with the third argument, so the correct parameters for the format
attribute are 2 and 3.
The format attribute allows you to identify your own functions which take format strings as arguments, so that GCC can check the
calls to these functions for errors. The compiler always (unless
-ffreestanding is used) checks formats for the standard library functions printf, fprintf, sprintf, scanf, fscanf, sscanf, strftime,
vprintf, vfprintf and vsprintf whenever such warnings are requested
(using -Wformat), so there is no need to modify the header file
stdio.h. In C99 mode, the functions snprintf, vsnprintf, vscanf,
vfscanf and vsscanf are also checked. Except in strictly conforming C
standard modes, the X/Open function strfmon is also checked as are
printf_unlocked and fprintf_unlocked. See Options Controlling C
Dialect.
Source: https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html
I'm creating my own kind of C library with my own kind of functions and also to help be better understand C and not just depend on GNU C Library for everything.
So far I got a bit of functions running but I wan't to tweak my printo function a little bit to support unlimited arguments (Restricted to chars only but your answer may also support passing in integer arguments). Here is the printo code:
#include "../GV.h"
#include "OtherUtils.h"
int print(char *WRITEOUT1){
char *WRITEOUT=&WRITEOUT1[0];
int AMOUNT=GetCharSize(WRITEOUT1);
register int SYSCALLNO asm("rax")=SYSWRITE;
register int FD asm("rdi")=STANDARDFD;
register char *BUF asm("rsi")=WRITEOUT;
register int BYTES asm("rdx")=AMOUNT;
asm("syscall");
return 0;
}
GetCharSize function code if anyone needs it:
#include "../GV.h"
int GetCharSize(char *arg){
for(i=0;arg[i]!='\0';i++){
}
return i;
}
GV.h has variables defined like int i;
Before I asked this question I looked into C pre-processors like __VA_ARGS__ but I somewhat couldn't wrap my head around it.
The ... notation is a part of the syntax of the C language. It is used in defining the argument list of a function as the last argument and means "followed by zero or more arguments of any type". E.g.
int printf (char *format, ...);
A function defined in this way can now be called with all the mandatory arguments, plus any number of additional arguments, like printf.
A function defined is this way must have a means of knowing how many arguments there are, and what the type of each argument is. printf knows this from the format specification string, the only required argument of printf.
Assuming an Intel system that uses a stack to pass arguments, and where arguments are pushed right-to-left (last argument pushed first), so the first optional argument will be directly after the format specification string on the stack, printf now proceeds as follows: take the address of the format specfication string and increment that address with the size of a char *. This is the start of the optional arguments. Now look at the format specifier string to know the type of the next argument; get that type of argument from the stack, increment it with the size of that argument to get the next address. Do this until there are no more format specifiers.
As you can see from the code snippet below, I have declared one char variable and one int variable. When the code gets compiled, it must identify the data types of variables str and i.
Why do I need to tell again during scanning my variable that it's a string or integer variable by specifying %s or %d to scanf? Isn't the compiler mature enough to identify that when I declared my variables?
#include <stdio.h>
int main ()
{
char str [80];
int i;
printf ("Enter your family name: ");
scanf ("%s",str);
printf ("Enter your age: ");
scanf ("%d",&i);
return 0;
}
Because there's no portable way for a variable argument functions like scanf and printf to know the types of the variable arguments, not even how many arguments are passed.
See C FAQ: How can I discover how many arguments a function was actually called with?
This is the reason there must be at least one fixed argument to determine the number, and maybe the types, of the variable arguments. And this argument (the standard calls it parmN, see C11(ISO/IEC 9899:201x) ยง7.16 Variable arguments ) plays this special role, and will be passed to the macro va_start. In another word, you can't have a function with a prototype like this in standard C:
void foo(...);
The reason why the compiler can not provide the necessary information is simply, because the compiler is not involved here. The prototype of the functions doesn't specify the types, because these functions have variable types. So the actual data types are not determined at compile time, but at runtime.
The function then takes one argument from the stack, after the other. These values don't have any type information associated with it, so the only way, the function knows how to interpret the data is, by using the caller provided information, which is the format string.
The functions themselves don't know which data types are passed in, nor do they know the number of arguments passed, so there is no way that printf can decide this on it's own.
In C++ you can use operator overloading, but this is an entire different mechanism. Because here the compiler chooses the appropriate function based on the datatypes and available overloaded function.
To illustrate this, printf, when compiled looks like this:
push value1
...
push valueN
push format_string
call _printf
And the prototype of printf is this:
int printf ( const char * format, ... );
So there is no type information carried over, except what is provided in the format string.
printf is not an intrinsic function. It's not part of the C language per se. All the compiler does is generate code to call printf, passing whatever parameters. Now, because C does not provide reflection as a mechanism to figure out type information at run time, the programmer has to explicitly provide the needed info.
Compiler may be smart, but functions printf or scanf are stupid - they do not know what is the type of the parameter do you pass for every call. This is why you need to pass %s or %d every time.
The first parameter is a format string. If you're printing a decimal number, it may look like:
"%d" (decimal number)
"%5d" (decimal number padded to width 5 with spaces)
"%05d" (decimal number padded to width 5 with zeros)
"%+d" (decimal number, always with a sign)
"Value: %d\n" (some content before/after the number)
etc, see for example Format placeholders on Wikipedia to have an idea what format strings can contain.
Also there can be more than one parameter here:
"%s - %d" (a string, then some content, then a number)
Isn't the compiler matured enough to identify that when I declared my
variable?
No.
You're using a language specified decades ago. Don't expect modern design aesthetics from C, because it's not a modern language. Modern languages will tend to trade a small amount of efficiency in compilation, interpretation or execution for an improvement in usability or clarity. C hails from a time when computer processing time was expensive and in highly limited supply, and its design reflects this.
It's also why C and C++ remain the languages of choice when you really, really care about being fast, efficient or close to the metal.
scanf as prototype int scanf ( const char * format, ... ); says stores given data according to the parameter format into the locations pointed by the additional arguments.
It is not related with compiler, it is all about syntax defined for scanf.Parameter format is required to let scanf know about the size to reserve for data to be entered.
GCC (and possibly other C compilers) keep track of argument types, at least in some situations. But the language is not designed that way.
The printf function is an ordinary function which accepts variable arguments. Variable arguments require some kind of run-time-type identification scheme, but in the C language, values do not carry any run time type information. (Of course, C programmers can create run-time-typing schemes using structures or bit manipulation tricks, but these are not integrated into the language.)
When we develop a function like this:
void foo(int a, int b, ...);
we can pass "any" number of additional arguments after the second one, and it is up to us to determine how many there are and what are their types using some sort of protocol which is outside of the function passing mechanism.
For instance if we call this function like this:
foo(1, 2, 3.0);
foo(1, 2, "abc");
there is no way that the callee can distinguish the cases. There are just some bits in a parameter passing area, and we have no idea whether they represent a pointer to character data or a floating point number.
The possibilities for communicating this type of information are numerous. For example in POSIX, the exec family of functions use variable arguments which have all the same type, char *, and a null pointer is used to indicate the end of the list:
#include <stdarg.h>
void my_exec(char *progname, ...)
{
va_list variable_args;
va_start (variable_args, progname);
for (;;) {
char *arg = va_arg(variable_args, char *);
if (arg == 0)
break;
/* process arg */
}
va_end(variable_args);
/*...*/
}
If the caller forgets to pass a null pointer terminator, the behavior will be undefined because the function will keep invoking va_arg after it has consumed all of the arguments. Our my_exec function has to be called like this:
my_exec("foo", "bar", "xyzzy", (char *) 0);
The cast on the 0 is required because there is no context for it to be interpreted as a null pointer constant: the compiler has no idea that the intended type for that argument is a pointer type. Furthermore (void *) 0 isn't correct because it will simply be passed as the void * type and not char *, though the two are almost certainly compatible at the binary level so it will work in practice. A common mistake with that type of exec function is this:
my_exec("foo", "bar", "xyzzy", NULL);
where the compiler's NULL happens to be defined as 0 without any (void *) cast.
Another possible scheme is to require the caller to pass down a number which indicates how many arguments there are. Of course, that number could be incorrect.
In the case of printf, the format string describes the argument list. The function parses it and extracts the arguments accordingly.
As mentioned at the outset, some compilers, notably the GNU C Compiler, can parse format strings at compile time and perform static type checking against the number and types of arguments.
However, note that a format string can be other than a literal, and may be computed at run
time, which is impervious to such type checking schemes. Fictitious example:
char *fmt_string = message_lookup(current_language, message_code);
/* no type checking from gcc in this case: fmt_string could have
four conversion specifiers, or ones not matching the types of
arg1, arg2, arg3, without generating any diagnostic. */
snprintf(buffer, sizeof buffer, fmt_string, arg1, arg2, arg3);
It is because this is the only way to tell the functions (like printf scanf) that which type of value you are passing. for example-
int main()
{
int i=22;
printf("%c",i);
return 0;
}
this code will print character not integer 22. because you have told the printf function to treat the variable as char.
printf and scanf are I/O functions that are designed and defined in a way to receive a control string and a list of arguments.
The functions does not know the type of parameter passed to it , and Compiler also cant pass this information to it.
Because in the printf you're not specifying data type, you're specifying data format. This is an important distinction in any language, and it's doubly important in C.
When you scan in a string with with %s, you're not saying "parse a string input for my string variable." You can't say that in C because C doesn't have a string type. The closest thing C has to a string variable is a fixed-size character array that happens to contain a characters representing a string, with the end of string indicated by a null character. So what you're really saying is "here's an array to hold the string, I promise it's big enough for the string input I want you to parse."
Primitive? Of course. C was invented over 40 years ago, when a typical machine had at most 64K of RAM. In such an environment, conserving RAM had a higher priority than sophisticated string manipulation.
Still, the %s scanner persists in more advanced programming environments, where there are string data types. Because it's about scanning, not typing.
what is "__printflike__ modifier" exactly? what does this term mean?
At a guess it tells the compiler you're using that a function takes arguments in the form [anything, ] format, ... where the format, ... part look like the arguments to printf. The __printflike__ attribute lets the compiler test the types in the argument list against the string format. This comes up when you write a function like log(format, ...) and use vsprintf to subordinate the formatting work to the usual standard library functions before sending the string to some special log interface.
If you are using GCC then it is probably a #define in your project something like:
#define __printflike__ __attribute__((format(printf, 1, 2)))
Where 1, 2 means that format, ... appear in positions 1 and 2.
I have a function in my error reporting library with the declaration in the header like:
extern void err_logmsg(FILE *fp, int flags, int estat, const char *format, ...)
PRINTFLIKE(4,5);
The PRINTFLIKE is in upper-case so that I can define it as nothing when I'm not using GCC. This use says that the first three arguments are nothing special, but the fourth argument is a format string like the ones used by printf() (indeed, internally, it gets passed to vfprintf()), and the arguments corresponding to it (formatted using the format string) start with the fifth argument.
This means that if I type:
err_logmsg(stdout, ERR_ABORT, 1, "%s: %d\n", errno, strerror(errno));
I will get a compilation error because errno is an int and strerror(errno) returns a pointer to a string. I can fix the error by changing the format string or the fifth and sixth arguments. (ERR_ABORT is a set of flags defined in the same header that declares err_logmsg().)
There are two numbers in the PRINTFLIKE macro because there could be other arguments between the format string and the first of the arguments used by the format string. For example, an alternative function could be:
extern void err_writer(FILE *fp, const char *format, int flags, int estat, ...)
PRINTFLIKE(2,5);
This tells the compiler that the format string is the second argument, but that the corresponding arguments that get formatted still appear starting at the fifth argument.
The header file for this code contains the lines:
#ifdef __GNUC__
#define PRINTFLIKE(n,m) __attribute__((format(printf,n,m)))
#define NORETURN() __attribute__((noreturn))
#else
#define PRINTFLIKE(n,m) /* If only */
#define NORETURN() /* If only */
#endif /* __GNUC__ */
Probably tells the compiler that the corresponding function has printf-like semantics.
This can enable the compiler to issue warnings at compile-time when the modifiers in the format string do not correspond to the type or the count of the passed arguments.
There is no other way that the compiler can have the knowledge to tell you that %u isn't the right formatting for an int when calling printf, sprintf, fprintf, etc.
I asked the reverse question a few months ago: Are printf/sprintf compiler warnings a conceptual break?