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

Discussion in 'C Programming' started by Rocke Robertson, Sep 30, 2003.

  1. 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);

    }
    Rocke Robertson, Sep 30, 2003
    #1
    1. Advertising

  2. Rocke Robertson <> wrote in
    news::

    > 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.

    --
    - Mark ->
    --
    Mark A. Odell, Sep 30, 2003
    #2
    1. Advertising

  3. "Mark A. Odell" wrote:

    > Rocke Robertson <> wrote in
    > news::
    >
    > > 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.
    >
    > --
    > - Mark ->
    > --


    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
    Rocke Robertson, Sep 30, 2003
    #3
  4. Rocke Robertson

    Eric Sosman Guest

    "Mark A. Odell" wrote:
    >
    > Rocke Robertson <> wrote in
    > news::
    >
    > > 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, Sep 30, 2003
    #4
  5. Rocke Robertson

    Eric Sosman Guest

    Rocke Robertson wrote:
    >
    > "Mark A. Odell" wrote:
    >
    > > Rocke Robertson <> wrote in
    > > news::
    > >
    > > > 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.
    > >
    > > --
    > > - Mark ->
    > > --

    >
    > 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.

    --
    Eric Sosman, Sep 30, 2003
    #5
  6. Rocke Robertson

    Richard Bos Guest

    Rocke Robertson <> wrote:

    > "Mark A. Odell" wrote:
    >
    > > Since popen(), which is not part of C, is not prototyped, C considers it
    > > to return type 'int'.

    >
    > 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
    Richard Bos, Sep 30, 2003
    #6
  7. Eric Sosman wrote:

    > 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.
    Rocke Robertson, Sep 30, 2003
    #7
  8. Rocke Robertson <> scribbled the following:
    > Eric Sosman wrote:
    >> 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.


    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 () ---------------------------\
    | 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
    Joona I Palaste, Sep 30, 2003
    #8
  9. Rocke Robertson

    Micah Cowan Guest

    Rocke Robertson <> writes:

    > 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
    news:comp.unix.programmer

    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
    Micah Cowan, Oct 1, 2003
    #9
  10. Eric Sosman wrote:

    > 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
    Rocke Robertson, Oct 1, 2003
    #10
  11. Rocke Robertson

    Dan Pop Guest

    In <> Rocke Robertson <> writes:

    >Eric Sosman wrote:
    >
    >> 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.


    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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 1, 2003
    #11
  12. Rocke Robertson

    Micah Cowan Guest

    [OT] Re: assignment makes pointer from integer without a cast...help please.

    (Dan Pop) writes:

    > 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
    Micah Cowan, Oct 1, 2003
    #12
  13. Rocke Robertson

    Dan Pop Guest

    Re: [OT] Re: assignment makes pointer from integer without a cast...help please.

    In <> Micah Cowan <> writes:

    > (Dan Pop) writes:
    >
    >> 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.


    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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 2, 2003
    #13
  14. Rocke Robertson

    Kevin Easton Guest

    Re: [OT] Re: assignment makes pointer from integer without a cast...help please.

    Micah Cowan <> wrote:
    > (Dan Pop) writes:
    >
    >> 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.


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

    - Kevin.
    Kevin Easton, Oct 2, 2003
    #14
  15. Rocke Robertson

    Dan Pop Guest

    Re: [OT] Re: assignment makes pointer from integer without a cast...help please.

    In <newscache$otp4mh$j6e$> Kevin Easton <> writes:

    >Micah Cowan <> wrote:
    >> (Dan Pop) writes:
    >>
    >>> 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.

    >
    >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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Oct 2, 2003
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Markus Dehmann
    Replies:
    14
    Views:
    921
    Irrwahn Grausewitz
    Jun 28, 2004
  2. Dawn Minnis
    Replies:
    4
    Views:
    1,534
    Dawn Minnis
    Feb 20, 2005
  3. Replies:
    2
    Views:
    1,228
    Martin Ambuhl
    Apr 1, 2005
  4. Juggernaut
    Replies:
    10
    Views:
    1,596
    CBFalconer
    Apr 9, 2005
  5. Zach
    Replies:
    3
    Views:
    7,551
Loading...

Share This Page