argv[argc] did not exist in Unix / K&R C.
NULL pointer is a later added feature against 'lazy' programming. This still doesn't make it a 'NULL-terminated' List, as there is no guarantee that the list doesn't already contain a NULL pointer due whatever previous processing.
argv is by definition an array (vector in BCPL notation) of string pointers with
argc elements thus only indices of 0..[argc-1] are valid. K&R's original The C Programming Language from 1978 includes only examples (chapter 5.11) where
argc is used to determinate boundries.
The same is true for all examples in 1988's second edition of The C Programming Language. No usage of
argv[argc]. But now a new half sentence is added on page 115: '...additionally, the standard requires that argv[argc] be a null pointer.' followed by an ilustration of an example vector. The 'standard' referenced here is the proposed ANSI standard which was basicly finished, but not published until 1989 (C89).
Before that, the X/Open group (holder of the Unix trademark back then) tried to define what Unix or better a unixoid environment should be by creating several standard books called XPG (X/Open Portability Guide). XPG2 from 1987 (?) defines among others the C programming language interface including the C-lib which in turn prepares argc/v when calling
main(). Here a new, last
NULL element for main's
argv was included.
The X/Open definitions are the most important source that went into C89. So it may be safe to see this as a point where it 'officially' entered C. Now which of the Unix(oide) systems did bring it into XPG2 is not fully known to me. AFAIK it is based on an implementation for some BULL system of the early 80s.
P.S.: And while it may be 'easy' to calculate the number of arguments by runing along the list until the first NULL is encountered, this is neither secure, nor free, but costs processing time. So why should a (user) program spend many cycles to calculate that number, when the calling program (OS/C-Lib) has already done the job while preparing the list? Remember, once upon a time programming was sensible and about performance :))