[scponly] Trivial patch for totally unnecessary helper.c compile
warning
Lorens Kockum
scponly-7264 at tagged.lorens.org
Mon Mar 3 15:54:09 EST 2003
When I compiled I looked at it and was surprised that such a
trivial thing had been left as-is, then I looked at the list
archives (because I have another issue to raise), and it seems
that it's the number-one question asked, with no answer other
than "it's just a warning, ignore it".
Well, since the patch is as trivial as can be, here it is . . .
-----8<--------------------------------------------------------------------------
--- helper.c 2002-12-17 01:24:36.000000000 +0100
+++ helper.c 2003-03-03 11:06:47.000000000 +0100
@@ -73,7 +73,7 @@
{
if (NULL != (crptr=strchr(*tmpptr, '\n')))
{
- *crptr=NULL;
+ *crptr='\0';
}
if (outbuf!=NULL)
{
@@ -164,7 +164,7 @@
{
if (NULL != (tmpstring=strchr((inputstring+1),'"')))
{
- *tmpstring++=NULL;
+ *tmpstring++='\0';
*ap=(inputstring+1);
#ifdef SOLARIS_COMPAT
-----8<--------------------------------------------------------------------------
For those who don't understand the warning or the patch, and
since I'm waiting for the client who wanted scp to call me
back: NULL is generally supposed to be a pointer. Some systems
#define NULL 0
while some
#define (void*)0
It depends on C-or-C++, ANSI standards, habits . . .:
Stock RedHat 8.0, /usr/include/libio.h:
#ifndef NULL
# if defined __GNUG__ && \
(__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 8))
# define NULL (__null)
# else
# if !defined(__cplusplus)
# define NULL ((void*)0)
# else
# define NULL (0)
# endif
# endif
#endif
It doesn't really matter to the code generated as long as it's 0
somehow.
But the compiler sees that you're assigning something that's
supposed to be a pointer to something that's supposed to be a
char.
That's a rather common C programming error (forgetting a *
somewhere, or putting one when one shouldn't . . .) Mostly
(when not assigning NULLs) those cause the program to fail
spectacularly in ways that are very similar, but completely
different, and which would be difficult to debug if you didn't
have the warning and if (some) Programming 101 teachers didn't
yell "No compiler warnings, not one, not unless you submit it
with a five-page paper explaining why the compiler is wrong and
why you can't avoid the warning!"
So the compiler gives its warning.
In this case, it's fairly obvious that the programmer meant
*tmpstring++='\0';
in order to terminate a C string, and not
tmpstring++=NULL ;
in order to do something mysterious with an array of strings,
but the compiler isn't expected to guess :-)
--
#include <std_disclaim.h> Lorens Kockum
More information about the scponly
mailing list