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