assignment makes pointer from integer without a cast...help please.

[Rocke Robertson]

Take it easy on me. I dont do a lot of programmng, only on a as needed
basis. For the life of me, I cant get rid of the error. Its the usual
casting problem. But I have cast the return type properly havent I ?

Here is the error....

larg.c: In function `page_n_loggit':
larg.c:29: warning: assignment makes pointer from integer without a cast

The error is refering to the popen() function. Below is all the code.

#include <stdio.h>
#include <stdlib.h>

page_n_loggit(char * host, char * str) {

static FILE *logfp;
static FILE *ptr;
char fn[] = " ";
char PatrolAlert[] = "Patrol Alert 1.0";
char PatrolLDAPErr[] = "CUSTOM_LDAP.gtis0.ldapStatus";
char alarm[] = "ALARM";
char *cmd;

/* Prime rand() */

srand(getpid());
sprintf(fn,"patfile.%d",rand());

if ((logfp = fopen(fn, "w")) == NULL)
perror("fopen failed");

fprintf(logfp,
"%s\n%s\n%s\n%s\n%s\n",PatrolAlert,PatrolLDAPErr,host,str,alarm);
fflush(logfp);
fclose(logfp);

sprintf(cmd, "/gtis/bin/ftp_file %s /alarm", fn);

if (( ptr = popen(cmd, "w")) == NULL)
perror("popen");

exit(0);

}

 

[Mark A. Odell]

The error is refering to the popen() function. Below is all the code.

#include <stdio.h>
#include <stdlib.h>

[snip]

if (( ptr = popen(cmd, "w")) == NULL)

Since popen(), which is not part of C, is not prototyped, C considers it
to return type 'int'. Since you are assigning the int return of this
popen() function to a pointer you get the error as expected. I suggest you
include the non-standard header file that has the prototype for popen()
and re-compile. If popen() is normally prototyped in stdio.h for your
system, be sure your compiler is pulling the correct version of stdio.h.

 

[Rocke Robertson]

The error is refering to the popen() function. Below is all the code.

#include <stdio.h>
#include <stdlib.h>
[snip]

if (( ptr = popen(cmd, "w")) == NULL)

Since popen(), which is not part of C, is not prototyped, C considers it
to return type 'int'. Since you are assigning the int return of this
popen() function to a pointer you get the error as expected. I suggest you
include the non-standard header file that has the prototype for popen()
and re-compile. If popen() is normally prototyped in stdio.h for your
system, be sure your compiler is pulling the correct version of stdio.h.

Shoot, maybe I should have posted to comp.unix.programmers because this is for
a unix system. In response to your comments, popen() is prototyped in stdio.h,
and I have included that header. There is only one version of stdio.h on the
system.

# ls /usr/include/stdio*
/usr/include/stdio.h /usr/include/stdio_impl.h
/usr/include/stdio_ext.h /usr/include/stdio_tag.h

Thanks

 

[Eric Sosman]

The error is refering to the popen() function. Below is all the code.

#include <stdio.h>
#include <stdlib.h>
[snip]

if (( ptr = popen(cmd, "w")) == NULL)

Since popen(), which is not part of C, is not prototyped, C considers it
to return type 'int'. Since you are assigning the int return of this
popen() function to a pointer you get the error as expected. I suggest you
include the non-standard header file that has the prototype for popen()
and re-compile. If popen() is normally prototyped in stdio.h for your
system, be sure your compiler is pulling the correct version of stdio.h.

In addition to the immediate error that Mark explained,
there are other problems with the code. For example,

char fn[] = " ";
...
sprintf(fn,"patfile.%d",rand());

is a recipe for disaster, and the other sprintf() call has
the problem described in Question 7.1 of the comp.lang.c
Frequently Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

There's also the little matter of detecting fopen() and
popen() failures (good) but doing nothing about them (bad).

 

[Eric Sosman]

The error is refering to the popen() function. Below is all the code.

#include <stdio.h>
#include <stdlib.h>
[snip]

if (( ptr = popen(cmd, "w")) == NULL)

Since popen(), which is not part of C, is not prototyped, C considers it
to return type 'int'. Since you are assigning the int return of this
popen() function to a pointer you get the error as expected. I suggest you
include the non-standard header file that has the prototype for popen()
and re-compile. If popen() is normally prototyped in stdio.h for your
system, be sure your compiler is pulling the correct version of stdio.h.

Shoot, maybe I should have posted to comp.unix.programmers because this is for
a unix system. In response to your comments, popen() is prototyped in stdio.h,
and I have included that header. There is only one version of stdio.h on the
system.

You will probably find that the popen() declaration is
guarded by #if or #ifdef preprocessor tests, and is not
"effectively" included if you're running the compiler in
a Standard-conforming mode. (In fact, if #include <stdio.h>
introduces a declaration of popen(), the implementation is
non-conforming; `popen' is in the space of names guaranteed
to be available to the programmer.)

You probably need to invoke the compiler in an "extended"
non-conforming mode, perhaps with something like `-DPOSIX_SOURCE'
on the command line. See your implementation's documentation
for details on how to get access to non-conforming language
extensions.

 

[Richard Bos]

Shoot, maybe I should have posted to comp.unix.programmers because this is for
a unix system. In response to your comments, popen() is prototyped in stdio.h,

Not in ISO C, it isn't.

Maybe the problem is that you're not only accidentally posting to an ISO
C newsgroup, but also accidentally compiling this as ISO C code. A
properly written header would then #ifdef out all non-ISO POSIX bits.
Try to find out what you need to #define to make your compiler assume
POSIX code (IIRC it's POSIX_SOURCE or similar).

Richard

 

[Rocke Robertson]

You will probably find that the popen() declaration is
guarded by #if or #ifdef preprocessor tests, and is not
"effectively" included if you're running the compiler in
a Standard-conforming mode. (In fact, if #include <stdio.h>
introduces a declaration of popen(), the implementation is
non-conforming; `popen' is in the space of names guaranteed
to be available to the programmer.)

You probably need to invoke the compiler in an "extended"
non-conforming mode, perhaps with something like `-DPOSIX_SOURCE'
on the command line. See your implementation's documentation
for details on how to get access to non-conforming language
extensions.

For what its worth, Im trying to build this on a Solaris 7 SPARC system using the
all too ubiquitous gcc 2.9.5.

 

[Joona I Palaste]

For what its worth, Im trying to build this on a Solaris 7 SPARC system using the
all too ubiquitous gcc 2.9.5.

Rule of thumb in comp.lang.c: If what OS, or what compiler, you are
using matters even the slightest bit, you're off-topic. So far I've
found this rule of thumb very useful.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen

 

[Micah Cowan]

Take it easy on me. I dont do a lot of programmng, only on a as needed
basis. For the life of me, I cant get rid of the error. Its the usual
casting problem. But I have cast the return type properly havent I ?

Here is the error....

larg.c: In function `page_n_loggit':
larg.c:29: warning: assignment makes pointer from integer without a cast

The error is refering to the popen() function. Below is all the code.

#include <stdio.h>
#include <stdlib.h>

page_n_loggit(char * host, char * str) {

static FILE *logfp;
static FILE *ptr;
char fn[] = " ";
char PatrolAlert[] = "Patrol Alert 1.0";
char PatrolLDAPErr[] = "CUSTOM_LDAP.gtis0.ldapStatus";
char alarm[] = "ALARM";
char *cmd;

/* Prime rand() */

srand(getpid());
sprintf(fn,"patfile.%d",rand());

if ((logfp = fopen(fn, "w")) == NULL)
perror("fopen failed");

fprintf(logfp,
"%s\n%s\n%s\n%s\n%s\n",PatrolAlert,PatrolLDAPErr,host,str,alarm);
fflush(logfp);
fclose(logfp);

sprintf(cmd, "/gtis/bin/ftp_file %s /alarm", fn);

if (( ptr = popen(cmd, "w")) == NULL)
perror("popen");

exit(0);

}

A lot of your code above, including popen(), is not standard C
and is thus offtopic here; it would be on-topic I believe at

I suspect that a declaration is not in scope for popen(), so its
return type is defaulting to int (BTW, the missing return type in
your function prototype for page_n_loggit() is illegal now in
C99). Make sure that you are invoking your compiler in such a way
to include extensions, or (better yet) #define the appropriate
macro before your #includes so that POSIX extensions are
included. For example:

#define _POSIX_C_SOURCE 199506L

#include <stdio.h>
#include <stdlib.h>

HTH,
Micah

 

[Rocke Robertson]

You will probably find that the popen() declaration is
guarded by #if or #ifdef preprocessor tests, and is not
"effectively" included if you're running the compiler in
a Standard-conforming mode. (In fact, if #include <stdio.h>
introduces a declaration of popen(), the implementation is
non-conforming; `popen' is in the space of names guaranteed
to be available to the programmer.)

You probably need to invoke the compiler in an "extended"
non-conforming mode, perhaps with something like `-DPOSIX_SOURCE'
on the command line. See your implementation's documentation
for details on how to get access to non-conforming language
extensions.

I added a #define _POSIX_SOURCE before I declare my headers and this fixed my
problems.
Sorry I was off topic, nevertheless, thanks for all your input.

~rocker

 

[Dan Pop]

I added a #define _POSIX_SOURCE before I declare my headers and this fixed my
problems.

This is the *wrong* fix, you have no business defining macros like
_POSIX_SOURCE in your code. The right thing is to learn how to invoke
your compiler in POSIX mode.

Dan

 

[Micah Cowan]

This is the *wrong* fix, you have no business defining macros like
_POSIX_SOURCE in your code. The right thing is to learn how to invoke
your compiler in POSIX mode.

Dan, defining such macros is what POSIX *requires* (2.2.1 in my
current draft copy); though the correct macro would be
_POSIX_C_SOURCE. AIUI, _POSIX_SOURCE is implementation-specific
(GNU?). Defining either of them invokes UB from the viewpoint of
Standard C; however, the results (of defining the latter, that
is) are very well-defined indeed on any POSIX platform, so,
assuming your target platforms are POSIX-supporting ones: no
problems.

-Micah

 

[Dan Pop]

Dan, defining such macros is what POSIX *requires* (2.2.1 in my
current draft copy); though the correct macro would be
_POSIX_C_SOURCE. AIUI, _POSIX_SOURCE is implementation-specific
(GNU?). Defining either of them invokes UB from the viewpoint of
Standard C; however, the results (of defining the latter, that
is) are very well-defined indeed on any POSIX platform, so,
assuming your target platforms are POSIX-supporting ones: no
problems.

The clean approach is to provide them at compiler invocation time, rather
than to hard code them in the program's sources. If you later want to
port the code to non-POSIX platforms, you can do something like this:

#ifndef _POSIX_C_SOURCE
/* provide a popen() replacement here */
#endif

If _POSIX_C_SOURCE is unconditionally defined in the source code, such an
approach is, obviously, not possible.

Dan

 

[Kevin Easton]

Dan, defining such macros is what POSIX *requires* (2.2.1 in my
current draft copy); though the correct macro would be
_POSIX_C_SOURCE. AIUI, _POSIX_SOURCE is implementation-specific
(GNU?). Defining either of them invokes UB from the viewpoint of
Standard C; however, the results (of defining the latter, that
is) are very well-defined indeed on any POSIX platform, so,
assuming your target platforms are POSIX-supporting ones: no
problems.

IOW, "#define _POSIX_C_SOURCE" is how that particular compiler is
supposed to be invoked in POSIX mode.

- Kevin.

 

[Dan Pop]

IOW, "#define _POSIX_C_SOURCE" is how that particular compiler is
supposed to be invoked in POSIX mode.

-D being a standard option of the POSIX C compiler, the right compiler
invocation is "c89 -D_POSIX_C_SOURCE". No need to mess with the source
code. On most POSIX platforms, a plain "cc" would be enough.

Dan