Lint
Ray Butterworth
rbutterworth at watmath.UUCP
Wed Apr 30 23:33:53 AEST 1986
> /* VARARGS */ and /*VARARGS0*/ both cause the first arg to be type-checked.
> Another 'bug' is that /* VARARGS */ is used for all varargs functions in
> llib-lc, where VARARGS1 should be used for printf, VARARGS2 for sprintf and
> fprintf, etc. grumble, grumble.
/*VARARGS*/ causes all the parameters in the function definition to be
type-checked. This is nearly always what you want. The dummy definition
for printf and fprintf in the lintlibrary file is something like:
/*VARARGS*/ printf(fmt) char*fmt; {return 0;}
/*VARARGS*/ fprintf(stream,fmt) FILE*stream; char*fmt; {return 0;}
This causes LINT to compare the types of ALL the parameters with the
supplied arguments. i.e. printf's first argument must be char*, and
it can take any type of arguments after that.
That /*VARARGS0*/ is treated the same as /*VARARGS*/ is in fact a bug
in LINT (if there is a number, it is stored as its negative value in
the 4.2 implementation, so -0 looks just like 0 which means that there
wasn't any number given).
One would almost never define a function with three parameters and
tell lint to check only the type of the first one or two. There seems
to be little point to ever doing such a thing. Unfortunately that is
what LINT takes the # in /*VARARGS#*/ to mean. A much more useful
meaning to the # would be to define the minimum number of arguments
that the caller must supply. e.g.
/*VARARGS1*/ func(n,a,b,c){return 0;}
would check the types of all four parameters (if arguments were passed
for them) and would complain if there wasn't at least one argument in
the call. But as I said, this is NOT what LINT does. In fact one can
call fprintf() with no arguments and get not a peep from LINT, regardless
of whether fprintf() is defined with /*VARARGS*/ or /*VARARGS2*/
Anyway, I believe that under X3J11's version, there won't be any need
for such a lint directive.
More information about the Comp.lang.c
mailing list