Missing prototype and resulting coredump in 64 bit machines - Linux

This is a discussion on Missing prototype and resulting coredump in 64 bit machines - Linux ; Hi, If i am not putting the function prototype of a function returning a pointer, i get a core dump.Though this will happen less probably on 32 bit machine example int main(int argc , char **argv) { char *base = ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Missing prototype and resulting coredump in 64 bit machines

  1. Missing prototype and resulting coredump in 64 bit machines

    Hi,
    If i am not putting the function prototype of a function
    returning a pointer, i get a core dump.Though this will happen less
    probably on 32 bit machine

    example
    int main(int argc , char **argv)
    {
    char *base = basename(argv[0]) ;
    printf("%s",base);
    return 0;

    }

    The compiler assumes that basename is returning an int and thus we
    loose 32 bit of the actual address, because pointer is 64 bit and
    integer is 32 bit in 64 bit machines

    I am working on
    Os linux x86_64 2.6.9
    Machine Hp
    compiler gcc 3.46

    Is there any option in GCC to make the default return value as long so
    that i can preserve the actual address returned

    Rakesh UV


  2. Re: Missing prototype and resulting coredump in 64 bit machines

    Rakesh UV writes:
    > If i am not putting the function prototype of a function
    > returning a pointer, i get a core dump.Though this will happen less
    > probably on 32 bit machine
    >
    > example
    > int main(int argc , char **argv)
    > {
    > char *base = basename(argv[0]) ;
    > printf("%s",base);
    > return 0;
    >
    > }
    >
    > The compiler assumes that basename is returning an int and thus we
    > loose 32 bit of the actual address, because pointer is 64 bit and
    > integer is 32 bit in 64 bit machines
    >
    > I am working on
    > Os linux x86_64 2.6.9
    > Machine Hp
    > compiler gcc 3.46
    >
    > Is there any option in GCC to make the default return value as long so
    > that i can preserve the actual address returned


    Did it occur to you that "if I don't tell the compiler the return type
    of some function I use, it does not generate working code" has the
    simple solution of telling the compiler?

  3. Re: Missing prototype and resulting coredump in 64 bit machines

    On 2007-10-18, Rakesh UV wrote:
    > If i am not putting the function prototype of a function
    > returning a pointer, i get a core dump.Though this will happen less
    > probably on 32 bit machine

    [...]
    > Is there any option in GCC to make the default return value as long so
    > that i can preserve the actual address returned


    Can't you provide a prototype? This is the most appropriate solution.
    Everything else will just make more troubles. If you use -Wall switch,
    then you'll get the list of functions without prototypes. Just go thru
    the list and add missing prototypes or "include".

    --
    Minds, like parachutes, function best when open

  4. Re: Missing prototype and resulting coredump in 64 bit machines

    Rakesh UV wrote:
    > If i am not putting the function prototype of a function
    > returning a pointer, i get a core dump.Though this will happen less
    > probably on 32 bit machine
    >
    > example
    > int main(int argc , char **argv)
    > {
    > char *base = basename(argv[0]) ;


    See any C FAQ why you are not supposed to cast the returnvalue of malloc().

    > Is there any option in GCC to make the default return value as long so
    > that i can preserve the actual address returned


    No and it shouldn't. Fix your code.

    Uli


  5. Re: Missing prototype and resulting coredump in 64 bit machines

    On Oct 18, 9:56 pm, Ulrich Eckhardt wrote:
    > Rakesh UV wrote:
    > > If i am not putting the function prototype of a function
    > > returning a pointer, i get a core dump.Though this will happen less
    > > probably on 32 bit machine

    >
    > > example
    > > int main(int argc , char **argv)
    > > {
    > > char *base = basename(argv[0]) ;

    >
    > See any C FAQ why you are not supposed to cast the returnvalue of malloc().
    >
    > > Is there any option in GCC to make the default return value as long so
    > > that i can preserve the actual address returned

    >
    > No and it shouldn't. Fix your code.
    >
    > Uli


    The suggestion where good, But the main issue not writing the
    prototype it is the size of the project and uncertain number of
    functions calls without prototype, I think i have to write by hand

    best Regards,
    rakesh Uv



  6. Re: Missing prototype and resulting coredump in 64 bit machines

    Rakesh UV wrote:

    > The suggestion where good, But the main issue not writing the
    > prototype it is the size of the project


    ... as in "control software for a nuclear power plant" or "flight
    software for the new Boebus A767"?

    > and uncertain number of
    > functions calls without prototype, I think i have to write by hand


    SCNR,

    Josef
    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html


  7. Re: Missing prototype and resulting coredump in 64 bit machines

    Ulrich Eckhardt writes:

    > Rakesh UV wrote:
    > > If i am not putting the function prototype of a function
    > > returning a pointer, i get a core dump.Though this will happen less
    > > probably on 32 bit machine
    > >
    > > example
    > > int main(int argc , char **argv)
    > > {
    > > char *base = basename(argv[0]) ;

    >
    > See any C FAQ why you are not supposed to cast the returnvalue of malloc().


    I'm missing why you're saying this. I don't see him casting, and I
    don't see a call to malloc(). I see a call to basename(), which is
    documented as returning char* (basename() may well be calling
    malloc(), but that's not his problem).

    I expect the other comments in the thread are correct, and his problem
    is failing to #include , which should be providing the prototype.

    > > Is there any option in GCC to make the default return value as long so
    > > that i can preserve the actual address returned

    >
    > No and it shouldn't. Fix your code.


    Correct.

  8. Re: Missing prototype and resulting coredump in 64 bit machines

    Rakesh UV writes:
    >
    > The suggestion where good, But the main issue not writing the
    > prototype it is the size of the project and uncertain number of
    > functions calls without prototype, I think i have to write by hand


    Porting broken code is no fun. For *years* I thought a null pointer
    was equivalent to a 0-length string. Turned out that on a VAX,
    address 0x00000000 was user-readable and happened (by what amounted
    from my perspective to a coincidence) to always contain 0. I don't
    remember how many hours I spent fixing my code when it moved to a Sun
    workstation...

  9. Re: Missing prototype and resulting coredump in 64 bit machines

    Joe Pfeiffer writes:
    > Ulrich Eckhardt writes:
    >
    >> Rakesh UV wrote:
    >> > If i am not putting the function prototype of a function
    >> > returning a pointer, i get a core dump.Though this will happen less
    >> > probably on 32 bit machine
    >> >
    >> > example
    >> > int main(int argc , char **argv)
    >> > {
    >> > char *base = basename(argv[0]) ;

    >>
    >> See any C FAQ why you are not supposed to cast the returnvalue of malloc().

    >
    > I'm missing why you're saying this. I don't see him casting, and I
    > don't see a call to malloc().


    When compiling with warnings enabled, assigning the return value of a
    subroutine without a visible prototype to a pointer will result in a
    warning. If the return value of a subroutine returning void * is
    casted to some other pointer type, for instance, because this is required in
    C++, this warning will be supressed. If there is no visible prototype
    and the code with the cast is compiled for a LP64-system, the compiler
    will silently generate a dysfunctional binary, which is the same
    situation as described above.

+ Reply to Thread