It depends on whether the problem is about issues with C or issues with
the 3rd party lib. For example there is a problem with the code:
execl("name", NULL);
To see that there's a problem you have to know that this is the POSIX
function (C doesn't define it), and that the POSIX execl() takes a
variable argument list of character pointers (the last of which must be a
null pointer). Once you know that the problem itself is entirely a C one.
Not everybody replying may spot that however, nor should they be expected
to.
If we provide the propotype for the execl function, a discussion on what
problems lie in the example is very much on topic:
from the Linux man page:
int execl( const char *path, const char *arg, ...);
In the example given, there really are 2 kinds of problems, one related to the
semantics of the execl() library function and system call, that specifies that
the first argument to execl is the pathname of a file to be executed, the second
and subsequent being a list of the arguments passed to that command as argv[0],
argv[1]... upto and including a NULL argument acting as a terminator.
execl("name", NULL);
will try and execute a file called "name" in the current directory, giving it a
NULL argv[0] and will scan extra arguments for NULL, invoking undefined
behaviour as no extra arguments were supplied.
Correcting this, and assuming "name" is indeed in the current directory, we
would get:
execl("name", "name", NULL);
However, there still is a problem with this piece of C code : passing NULL to un
unprototyped function or one with a variable list of arguments may not have the
intended effect : NULL can be defined as 0, and thus would be passed as an 'int'
instead of a 'const char*' possibly of different size, and the alternative
definition of NULL as ((void*)0) would also fail to pass the pointer correctly
on weird architectures where all pointer types do not have the same encoding.
One can correct this as:
execl("name", "name", (char*)NULL);
