conflict function definition with stdlib.h

Discussion in 'C Programming' started by hqin, Jan 15, 2011.

  1. hqin

    hqin Guest

    I am having problem to compile a software on my computers. The
    software is written in C and it defines a function with the same name
    in /usr/include/stdlib.h file.The compile complains about the
    conflicted definition and bailed out.
    This software is a mathematic software that I do not want to modify.
    Is there a simple way to get around this problem?

    Thanks.
     
    hqin, Jan 15, 2011
    #1
    1. Advertising

  2. hqin

    PKM Guest

    On Jan 14, 7:28 pm, hqin <> wrote:
    > I am having problem to compile a software on my computers. The
    > software is written in C and it defines a function with the same name
    > in /usr/include/stdlib.h file.The compile complains about the
    > conflicted definition and bailed out.
    > This software is a mathematic software that I do not want to modify.
    > Is there a simple way to get around this problem?
    >
    > Thanks.


    What I do is prefix "k" to the name of any of the functions
    I write which might conflict with a standard library function,
    as in ksqrt(). Use your own initial, though.

    Alternatively, maybe you can set your linker to use your function
    instead.
    Check the manual.

    What is the code, anyway?
     
    PKM, Jan 15, 2011
    #2
    1. Advertising

  3. hqin <> writes:

    > I am having problem to compile a software on my computers. The
    > software is written in C and it defines a function with the same name
    > in /usr/include/stdlib.h file.The compile complains about the
    > conflicted definition and bailed out.
    > This software is a mathematic software that I do not want to modify.
    > Is there a simple way to get around this problem?


    Maybe. More detail would help.

    Sometimes this is simply due to using the wrong compiler options -- for
    example permitting language extensions rather using standard C. It
    would help if you said what the function is and what compiler switches
    you use (and which ones you think you need).

    --
    Ben.
     
    Ben Bacarisse, Jan 15, 2011
    #3
  4. hqin

    hqin Guest

    Here is the compiling error:

    ace:src hqin$ make
    gcc -O3 -Wall -c -o misc.o misc.c
    In file included from misc.c:21:
    misc.h:106: error: conflicting types for ‘psort’
    /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    here
    misc.c:748: error: conflicting types for ‘psort’
    /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    here
    make: *** [misc.o] Error 1

    I am trying to compile a software CONSEL (http://www.is.titech.ac.jp/
    ~shimo/prog/consel/) on a Mac OsX system.
    I also tried an recent Ubuntu machine and received the same error.
    This is weir because Ubuntu is derived from Debian. Oddly enough, I
    tried on a old version of Ubuntu machine and the problem went away.
    (But this old machine is not usable for my computing project)

    The original software was developed in a Debian system. It would be
    great if I can use different gcc switches to get around this.

    I am glad that people have responded to this post even on a weekend.
    THANKS!


    On Jan 14, 10:17 pm, Ben Bacarisse <> wrote:
    > hqin <> writes:
    > > I am having problem to compile a software on my computers. The
    > > software is written in C and it defines a function with the same name
    > > in /usr/include/stdlib.h file.The compile complains about the
    > > conflicted definition and bailed out.
    > > This software is a mathematic software that I do not want to modify.
    > > Is there a simple way to get around this problem?

    >
    > Maybe.  More detail would help.
    >
    > Sometimes this is simply due to using the wrong compiler options -- for
    > example permitting language extensions rather using standard C.  It
    > would help if you said what the function is and what compiler switches
    > you use (and which ones you think you need).
    >
    > --
    > Ben.
     
    hqin, Jan 15, 2011
    #4
  5. hqin

    hqin Guest

    Here is the Makefile

    CC = gcc
    #CFLAGS = -g -Wall
    CFLAGS = -O3 -Wall
    LDLIBS = -lm


    targets= makermt catpv catci catrep treeass consel randrep catmt seqmt
    makerep catass
    objects= misc.o rand.o tree.o freadmat.o opt.o mt19937.o
    bindir=../bin

    all: $(targets)

    makermt: misc.o rand.o freadmat.o mt19937.o
    catpv: misc.o
    treeass: tree.o misc.o
    consel: misc.o rand.o opt.o mt19937.o
    catmt: misc.o rand.o mt19937.o
    seqmt: freadmat.o misc.o

    makerep: misc.o rand.o freadmat.o mt19937.o
    catci: misc.o
    catrep: misc.o
    catass: misc.o
    randrep: misc.o rand.o mt19937.o

    test: rand.o misc.o mt19937.o
    tabpv1: misc.o
    tabpv2: misc.o
    tabpv4: misc.o
     
    hqin, Jan 15, 2011
    #5
  6. hqin

    PKM Guest

    Weird. I tried it on an Ubuntu machine,
    and here's what happened:

    $ make

    gcc -O3 -Wall -c -o misc.o misc.c
    In file included from misc.c:21:
    misc.h:19: error: conflicting types for ‘dprintf’
    /usr/include/stdio.h:397: note: previous declaration of ‘dprintf’ was
    here
    misc.c:30: error: conflicting types for ‘dprintf’
    /usr/include/stdio.h:397: note: previous declaration of ‘dprintf’ was
    here
    make: *** [misc.o] Error 1

    So... I would contact the maintainer of the software, if I were you.
     
    PKM, Jan 15, 2011
    #6
  7. hqin

    Eric Sosman Guest

    On 1/15/2011 12:58 PM, hqin wrote:
    > Here is the compiling error:
    >
    > ace:src hqin$ make
    > gcc -O3 -Wall -c -o misc.o misc.c
    > In file included from misc.c:21:
    > misc.h:106: error: conflicting types for ‘psort’
    > /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    > here
    >[...]


    A Standard-conforming <stdlib.h> must not even mention `psort',
    much less declare it. However, gcc's default mode of operation is
    not Standard-conforming: it compiles a sort of C-with-extras dialect
    rather than C. If you provide the right compilation flags, gcc will
    at least attempt to conform to the Standard, and in this mode will
    almost certainly not declare `psort' in <stdlib.h>. Try adding the
    `-ansi -pedantic' flags (or `-std=c99 -pedantic' if the code is
    fairly new). You may need to remove `-pedantic', as lots of code
    isn't clean enough for it, but you'll surely need one of the others.

    Unfortunately, I sort of suspect this won't solve the problem
    altogether. In light of the report elsethread that `dprintf' is also
    doubly declared, it may turn out that the code contains its own
    "free-hand" declarations of these identifiers, and expects to find
    them in a library. If that's the case, the real cure is probably to
    drop `-ansi' (or `-std=c99') and to delete the offending declarations
    from the source. But try changing the flags first: Cross the other
    bridge only if you actually come to it.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 15, 2011
    #7
  8. hqin

    hqin Guest

    Here is my solution to this problem.

    First, I commented out the conflict definitions in <stdlib.h>. Then,
    "make" runs with some warnings. I tested the software using its
    example data, and it seems to be OK. So, I assume the software is
    compiled correctly.

    Then, to avoid causing problems to other software on my osX, I
    restored the original <stdlib.h> file.

    I also emailed the author of the software.

    Thanks to everyone that have responded. Enjoy the rest of the weekend.

    Hong Qin
     
    hqin, Jan 15, 2011
    #8
  9. hqin

    James Waldby Guest

    On Sat, 15 Jan 2011 15:08:17 -0500, Eric Sosman wrote:
    > On 1/15/2011 12:58 PM, hqin wrote:
    >> Here is the compiling error:
    >> ace:src hqin$ make
    >> gcc -O3 -Wall -c -o misc.o misc.c
    >> In file included from misc.c:21:
    >> misc.h:106: error: conflicting types for ‘psort’
    >> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >> here
    >>[...]

    > A Standard-conforming <stdlib.h> must not even mention `psort',
    > much less declare it. However, gcc's default mode of operation is not
    > Standard-conforming: it compiles a sort of C-with-extras dialect rather
    > than C. If you provide the right compilation flags, gcc will at least
    > attempt to conform to the Standard, and in this mode will almost
    > certainly not declare `psort' in <stdlib.h>. Try adding the `-ansi
    > -pedantic' flags (or `-std=c99 -pedantic' if the code is fairly new).
    > You may need to remove `-pedantic', as lots of code isn't clean enough
    > for it, but you'll surely need one of the others.


    Can you provide a reference that indicates `psort' is a GNU or gcc
    extension? I've seen web pages that refer to BSD and Mac but not GNU.

    > Unfortunately, I sort of suspect this won't solve the problem
    > altogether. In light of the report elsethread that `dprintf' is also
    > doubly declared, [...]


    For `dprintf' it's clear that both GNU and Apple are guilty of
    extension. According to "info dprintf" on linux,

    "These functions are GNU extensions, not in C or POSIX.
    Clearly, the names were badly chosen. Many systems (like
    MacOS) have incompatible functions called dprintf(),
    usually some debugging version of printf() ..."

    --
    jiw
     
    James Waldby, Jan 16, 2011
    #9
  10. hqin

    Eric Sosman Guest

    On 1/15/2011 7:35 PM, James Waldby wrote:
    > On Sat, 15 Jan 2011 15:08:17 -0500, Eric Sosman wrote:
    >> On 1/15/2011 12:58 PM, hqin wrote:
    >>> Here is the compiling error:
    >>> ace:src hqin$ make
    >>> gcc -O3 -Wall -c -o misc.o misc.c
    >>> In file included from misc.c:21:
    >>> misc.h:106: error: conflicting types for ‘psort’
    >>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>> here
    >>> [...]

    >> A Standard-conforming<stdlib.h> must not even mention `psort',
    >> much less declare it. [...]

    >
    > Can you provide a reference that indicates `psort' is a GNU or gcc
    > extension? I've seen web pages that refer to BSD and Mac but not GNU.


    It's not really a matter of which extension or addition or
    decoration `psort' belongs to: The point is that the C Standard
    does not list `psort' as one of the identifiers <stdlib.h> is
    allowed to declare. It is an identifier in the programmer's "name
    space," an identifier the programmer must be able to use freely
    without fear that <stdlib.h> or <ctype.h> or <whatever.h> or the
    compiler itself will somehow use in a conflicting way. As a
    programmer, you can use `x' in any way you choose; same with `psort'.

    >> Unfortunately, I sort of suspect this won't solve the problem
    >> altogether. In light of the report elsethread that `dprintf' is also
    >> doubly declared, [...]

    >
    > For `dprintf' it's clear that both GNU and Apple are guilty of
    > extension. According to "info dprintf" on linux,
    >
    > "These functions are GNU extensions, not in C or POSIX.
    > Clearly, the names were badly chosen. Many systems (like
    > MacOS) have incompatible functions called dprintf(),
    > usually some debugging version of printf() ..."


    It's a continuing problem. The C Standard recognizes only two
    classes of code-writers: "implementors" and "users." The Standard
    carefully divides the identifier name space into three parts, like
    Caesar's Gaul: (1) identifiers that the implementors must provide
    and that the users can rely upon, (2) identifiers the implementors
    can use for whatever purposes they please, and (3) identifiers that
    the users can employ for whatever purposes *they* please. This gives
    a measure of sanity: The users can be sure that the implementors will
    not misappropriate `farthingale', and the implementors can be sure
    that the users will not try to use `EFFORT'. (Yes, the division is
    sometimes very peculiar; put it down to "hysterical raisins.")

    *But* the Standard offers no way for different groups of "users"
    to identify themselves and to avoid trampling on each other's names.
    If you want to use a popular extension like POSIX, you must give up
    on trying to use `fork' as an identifier of your own. If you want to
    use the Fastest Fourier Transform in the West, you must avoid trying
    to use `fftw_complex' for your own purposes. Eventually, you will
    surely find that extension A and library B both define `dingbat', and
    do so incompatibly. The "badly chosen" names mentioned in the man
    page are really not the fault of the choosers; it is inevitable that
    conflicts of this kind will arise. And C per se offers no solution.

    C'est la vie.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 16, 2011
    #10
  11. hqin

    Geoff Guest

    On Sat, 15 Jan 2011 15:08:17 -0500, Eric Sosman
    <> wrote:

    >On 1/15/2011 12:58 PM, hqin wrote:
    >> Here is the compiling error:
    >>
    >> ace:src hqin$ make
    >> gcc -O3 -Wall -c -o misc.o misc.c
    >> In file included from misc.c:21:
    >> misc.h:106: error: conflicting types for ‘psort’
    >> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >> here
    >>[...]

    >
    > A Standard-conforming <stdlib.h> must not even mention `psort',
    >much less declare it. However, gcc's default mode of operation is
    >not Standard-conforming: it compiles a sort of C-with-extras dialect
    >rather than C. If you provide the right compilation flags, gcc will
    >at least attempt to conform to the Standard, and in this mode will
    >almost certainly not declare `psort' in <stdlib.h>. Try adding the
    >`-ansi -pedantic' flags (or `-std=c99 -pedantic' if the code is
    >fairly new). You may need to remove `-pedantic', as lots of code
    >isn't clean enough for it, but you'll surely need one of the others.
    >
    > Unfortunately, I sort of suspect this won't solve the problem
    >altogether. In light of the report elsethread that `dprintf' is also
    >doubly declared, it may turn out that the code contains its own
    >"free-hand" declarations of these identifiers, and expects to find
    >them in a library. If that's the case, the real cure is probably to
    >drop `-ansi' (or `-std=c99') and to delete the offending declarations
    >from the source. But try changing the flags first: Cross the other
    >bridge only if you actually come to it.


    It appears to be an Apple extension in OS X 10.6.x that didn't appear
    in OS X 10.4.x. Their man page reads (reformatted):

    PSORT(3) BSD Library Functions Manual PSORT(3)

    NAME
    psort, psort_b, psort_r -- parallel sort functions

    SYNOPSIS
    #include <stdlib.h>

    void
    psort(void *base, size_t nel, size_t width,
    int (*compar)(const void *, const void *));

    void
    psort_b(void *base, size_t nel, size_t width,
    int (^compar)(const void *, const void *));

    void
    psort_r(void *base, size_t nel, size_t width, void *thunk,
    int (*compar)(void *, const void *, const void *));

    DESCRIPTION
    The psort(), psort_b(), and psort_r() functions are parallel sort
    routines that are drop-in compatible with the corresponding
    qsort() function (see qsort(3) for a description of the
    arguments). On multi-processor machines, multiple threads may be
    created to simultaneously perform the sort calculations,
    resulting in an overall faster sort result. Overhead in managing
    the threads limits the maximum speed improvement to somewhat less
    that the number of processors available. For example, on a
    4-processor machine, a typical sort on a large array might result
    in 3.2 times faster sorting than a regular qsort().

    RESTRICTIONS
    Because of the multi-threaded nature of the sort, the comparison
    function is expected to perform its own synchronization that
    might be required for data physically outside the two objects
    passed to the comparison function. However, no synchronization
    is required for the two object themselves, unless some third
    party is also accessing those objects.

    Additional memory is temporary allocated to deal with the
    parallel nature of the computation.

    Because of the overhead of maintaining multiple threads, the
    psort() family of routines may choose to just call qsort(3) when
    there is no advantage to parallelizing (for example, when the
    number of objects in the array is too small, or only one
    processor is available).

    Like qsort(3), the sort is not stable.

    RETURN VALUES
    The psort(), psort_b() and psort_r() functions return no value.

    SEE ALSO
    qsort(3)

    Mac OS X Nov 25, 2008 Mac OS X


    I doesn't matter what dialect you choose.
     
    Geoff, Jan 16, 2011
    #11
  12. On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin <>
    wrote:

    >Here is the compiling error:
    >
    >ace:src hqin$ make
    >gcc -O3 -Wall -c -o misc.o misc.c
    >In file included from misc.c:21:
    >misc.h:106: error: conflicting types for ‘psort’
    >/usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >here
    >misc.c:748: error: conflicting types for ‘psort’
    >/usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >here
    >make: *** [misc.o] Error 1



    After the

    #include <stdlib.h>

    add

    #undef psort

    and then

    #include "misc.h"

    The "#undef psort" stops the psort being referenced from “stdlib.h”
    so it can be referenced from "misc.h" and that makes for a happy
    compiler.
     
    Richard Sanders, Jan 16, 2011
    #12
  13. hqin

    Eric Sosman Guest

    On 1/16/2011 3:59 AM, Richard Sanders wrote:
    > On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
    > wrote:
    >
    >> Here is the compiling error:
    >>
    >> ace:src hqin$ make
    >> gcc -O3 -Wall -c -o misc.o misc.c
    >> In file included from misc.c:21:
    >> misc.h:106: error: conflicting types for ‘psort’
    >> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >> here
    >> misc.c:748: error: conflicting types for ‘psort’
    >> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >> here
    >> make: *** [misc.o] Error 1

    >
    >
    > After the
    >
    > #include<stdlib.h>
    >
    > add
    >
    > #undef psort
    >
    > and then
    >
    > #include "misc.h"
    >
    > The "#undef psort" stops the psort being referenced from “stdlib.h”
    > so it can be referenced from "misc.h" and that makes for a happy
    > compiler.


    It might be worth a try, but I doubt it will help. From the
    wording of the error messages, it looks like `psort' has been
    declared as an ordinary identifier, not as (or not only as) a
    macro. The #undef will erase a macro definition, if there is
    one, but will not affect the visibility of the plain identifier:

    int x;
    #undef x
    double x; // error, despite the #undef

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 16, 2011
    #13
  14. hqin wrote:
    > Here is my solution to this problem.
    >
    > First, I commented out the conflict definitions in <stdlib.h>. Then,
    > "make" runs with some warnings. I tested the software using its
    > example data, and it seems to be OK. So, I assume the software is
    > compiled correctly.
    >
    > Then, to avoid causing problems to other software on my osX, I
    > restored the original <stdlib.h> file.


    I'd still suggest you try the -std=c99 option. Just modify the CFLAGS
    line in the Makefile so it says

    CFLAGS = -O3 -Wall -std=c99

    If that fails too, try -ansi instead of -std=c99.
    If it works, you'll have a simple way to compile the software without
    touching either its code or your system files.
    --
    Marcin Grzegorczyk
     
    Marcin Grzegorczyk, Jan 16, 2011
    #14
  15. hqin

    None Guest

    On Jan 15, 9:58 am, hqin <> wrote:
    > Here is the compiling error:
    >
    > ace:src hqin$ make
    > gcc -O3 -Wall   -c -o misc.o misc.c
    > In file included from misc.c:21:
    > misc.h:106: error: conflicting types for ‘psort’
    > /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    > here
    > misc.c:748: error: conflicting types for ‘psort’
    > /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    > here
    > make: *** [misc.o] Error 1
    >
    > I am trying to compile a software CONSEL (http://www.is.titech.ac.jp/
    > ~shimo/prog/consel/) on a Mac OsX system.
    > I also tried an recent Ubuntu machine and received the same error.
    > This is weir because Ubuntu is derived from Debian. Oddly enough, I
    > tried on a old version of Ubuntu machine and the problem went away.
    > (But this old machine is not usable for my computing project)
    >
    > The original software was developed in a Debian system. It would be
    > great if I can use different gcc switches to get around this.
    >
    > I am glad that people have responded to this post even on a weekend.
    > THANKS!
    >


    Unfortunately, Apple has decided to pollute the user namespace by
    declaring
    non-standard extensions psort, psort_b and psort_r in <stdlib.h> and
    Ubuntu has
    declared the non-standard dprintf in their header, even when there is
    supposed to be a standardized method for naming non-standard
    extensions.

    Your safest and simplest method is to rename the CONSEL psort function
    to
    p_sort and be done with it. The name only occurs once in each of only
    4
    files in the source and it is far easier to edit this code than to
    play
    games with the "standard" headers of OS X, Debian, Ubuntu and all the
    flavors of GCC floating around.
     
    None, Jan 16, 2011
    #15
  16. hqin

    Geoff Guest

    On Sun, 16 Jan 2011 11:35:07 -0800 (PST), None
    <> wrote:

    >On Jan 15, 9:58 am, hqin <> wrote:
    >> Here is the compiling error:
    >>
    >> ace:src hqin$ make
    >> gcc -O3 -Wall   -c -o misc.o misc.c
    >> In file included from misc.c:21:
    >> misc.h:106: error: conflicting types for ‘psort’
    >> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >> here
    >> misc.c:748: error: conflicting types for ‘psort’
    >> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >> here
    >> make: *** [misc.o] Error 1
    >>
    >> I am trying to compile a software CONSEL (http://www.is.titech.ac.jp/
    >> ~shimo/prog/consel/) on a Mac OsX system.
    >> I also tried an recent Ubuntu machine and received the same error.
    >> This is weir because Ubuntu is derived from Debian. Oddly enough, I
    >> tried on a old version of Ubuntu machine and the problem went away.
    >> (But this old machine is not usable for my computing project)
    >>
    >> The original software was developed in a Debian system. It would be
    >> great if I can use different gcc switches to get around this.
    >>
    >> I am glad that people have responded to this post even on a weekend.
    >> THANKS!
    >>

    >
    >Unfortunately, Apple has decided to pollute the user namespace by
    >declaring
    >non-standard extensions psort, psort_b and psort_r in <stdlib.h> and
    >Ubuntu has
    >declared the non-standard dprintf in their header, even when there is
    >supposed to be a standardized method for naming non-standard
    >extensions.
    >
    >Your safest and simplest method is to rename the CONSEL psort function
    >to
    >p_sort and be done with it. The name only occurs once in each of only
    >4
    >files in the source and it is far easier to edit this code than to
    >play
    >games with the "standard" headers of OS X, Debian, Ubuntu and all the
    >flavors of GCC floating around.
    >


    On OS X, add -D_ANSI_SOURCE to your CFLAGS in the Makefile.
     
    Geoff, Jan 16, 2011
    #16
  17. On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
    <> wrote:

    >On 1/16/2011 3:59 AM, Richard Sanders wrote:
    >> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
    >> wrote:
    >>
    >>> Here is the compiling error:
    >>>
    >>> ace:src hqin$ make
    >>> gcc -O3 -Wall -c -o misc.o misc.c
    >>> In file included from misc.c:21:
    >>> misc.h:106: error: conflicting types for ‘psort’
    >>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>> here
    >>> misc.c:748: error: conflicting types for ‘psort’
    >>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>> here
    >>> make: *** [misc.o] Error 1

    >>
    >>
    >> After the
    >>
    >> #include<stdlib.h>
    >>
    >> add
    >>
    >> #undef psort
    >>
    >> and then
    >>
    >> #include "misc.h"
    >>
    >> The "#undef psort" stops the psort being referenced from “stdlib.h”
    >> so it can be referenced from "misc.h" and that makes for a happy
    >> compiler.

    >
    > It might be worth a try, but I doubt it will help. From the
    >wording of the error messages, it looks like `psort' has been
    >declared as an ordinary identifier, not as (or not only as) a
    >macro. The #undef will erase a macro definition, if there is
    >one, but will not affect the visibility of the plain identifier:
    >
    > int x;
    > #undef x
    > double x; // error, despite the #undef


    You are trying to undef a variable not a function.

    #undef psort

    It is called function overriding and it does work and has for me since
    my turbo c days.

    Rather than ruminating just try it. The thing to remember is that the
    #undef is only valid for the source file it appeares in.
     
    Richard Sanders, Jan 16, 2011
    #17
  18. hqin

    Eric Sosman Guest

    On 1/16/2011 3:08 PM, Richard Sanders wrote:
    > On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
    > <> wrote:
    >
    >> On 1/16/2011 3:59 AM, Richard Sanders wrote:
    >>> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
    >>> wrote:
    >>>
    >>>> Here is the compiling error:
    >>>>
    >>>> ace:src hqin$ make
    >>>> gcc -O3 -Wall -c -o misc.o misc.c
    >>>> In file included from misc.c:21:
    >>>> misc.h:106: error: conflicting types for ‘psort’
    >>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>>> here
    >>>> misc.c:748: error: conflicting types for ‘psort’
    >>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>>> here
    >>>> make: *** [misc.o] Error 1
    >>>
    >>>
    >>> After the
    >>>
    >>> #include<stdlib.h>
    >>>
    >>> add
    >>>
    >>> #undef psort
    >>>
    >>> and then
    >>>
    >>> #include "misc.h"
    >>>
    >>> The "#undef psort" stops the psort being referenced from “stdlib.h”
    >>> so it can be referenced from "misc.h" and that makes for a happy
    >>> compiler.

    >>
    >> It might be worth a try, but I doubt it will help. From the
    >> wording of the error messages, it looks like `psort' has been
    >> declared as an ordinary identifier, not as (or not only as) a
    >> macro. The #undef will erase a macro definition, if there is
    >> one, but will not affect the visibility of the plain identifier:
    >>
    >> int x;
    >> #undef x
    >> double x; // error, despite the #undef

    >
    > You are trying to undef a variable not a function.


    #undef does not apply to variables nor to functions, but to
    macros. At the time #undef is processed (and at the time macros
    are expanded), there is no difference between a "variable" and
    a "function." Not even `int' has any meaning beyond than "I am a
    three-character token."

    > #undef psort
    >
    > It is called function overriding and it does work and has for me since
    > my turbo c days.


    I have no personal experience with Turbo C. However, no C
    compiler I've ever used has processed #undef any differently for
    macros whose names look like functions than for macros whose
    names look like something else. Certainly no Standard-conforming
    compiler has ever done so.

    > Rather than ruminating just try it. The thing to remember is that the
    > #undef is only valid for the source file it appeares in.


    Good advice. What happened when you tried it?

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 16, 2011
    #18
  19. On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
    <> wrote:

    >On 1/16/2011 3:08 PM, Richard Sanders wrote:
    >> On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
    >> <> wrote:
    >>
    >>> On 1/16/2011 3:59 AM, Richard Sanders wrote:
    >>>> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
    >>>> wrote:
    >>>>
    >>>>> Here is the compiling error:
    >>>>>
    >>>>> ace:src hqin$ make
    >>>>> gcc -O3 -Wall -c -o misc.o misc.c
    >>>>> In file included from misc.c:21:
    >>>>> misc.h:106: error: conflicting types for ‘psort’
    >>>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>>>> here
    >>>>> misc.c:748: error: conflicting types for ‘psort’
    >>>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
    >>>>> here
    >>>>> make: *** [misc.o] Error 1
    >>>>
    >>>>
    >>>> After the
    >>>>
    >>>> #include<stdlib.h>
    >>>>
    >>>> add
    >>>>
    >>>> #undef psort
    >>>>
    >>>> and then
    >>>>
    >>>> #include "misc.h"
    >>>>
    >>>> The "#undef psort" stops the psort being referenced from “stdlib.h”
    >>>> so it can be referenced from "misc.h" and that makes for a happy
    >>>> compiler.
    >>>
    >>> It might be worth a try, but I doubt it will help. From the
    >>> wording of the error messages, it looks like `psort' has been
    >>> declared as an ordinary identifier, not as (or not only as) a
    >>> macro. The #undef will erase a macro definition, if there is
    >>> one, but will not affect the visibility of the plain identifier:
    >>>
    >>> int x;
    >>> #undef x
    >>> double x; // error, despite the #undef

    >>
    >> You are trying to undef a variable not a function.

    >
    > #undef does not apply to variables nor to functions, but to
    >macros. At the time #undef is processed (and at the time macros
    >are expanded), there is no difference between a "variable" and
    >a "function." Not even `int' has any meaning beyond than "I am a
    >three-character token."
    >
    >> #undef psort
    >>
    >> It is called function overriding and it does work and has for me since
    >> my turbo c days.

    >
    > I have no personal experience with Turbo C. However, no C
    >compiler I've ever used has processed #undef any differently for
    >macros whose names look like functions than for macros whose
    >names look like something else. Certainly no Standard-conforming
    >compiler has ever done so.
    >
    >> Rather than ruminating just try it. The thing to remember is that the
    >> #undef is only valid for the source file it appeares in.

    >
    > Good advice. What happened when you tried it?



    It seems to work. Try my example.

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

    #undef printf
    /*
    ** int printf (const char*, ...);
    */

    int printf(const char* str, ...)
    {
    fprintf(stdout, "12345");
    return 0;
    }


    int main()
    {
    printf("Hello world!\n");
    return 0;
    }

    If the output is "12345" then my own version of printf is used and not
    the library version. I got "12345". Had I got "Hello world!" then I
    would be wrong and you would be right.

    Also note that my implimentation uses the exact same declaration as in
    the header file.

    "#undef printf" means do not link the libray version, link the
    supplied version, it has nothing to do with header files.
     
    Richard Sanders, Jan 16, 2011
    #19
  20. On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
    <> wrote:
    [snip]
    >> You are trying to undef a variable not a function.

    >
    > #undef does not apply to variables nor to functions, but to
    >macros.


    In my previous post I forgot to aknowledge that if a function is
    implimented as a #define then the macro is undefined.

    The end result is the same. The library function is not linked and the
    custom function is and that is the whole point of it, to be able to
    replace library functions with a custom function.
     
    Richard Sanders, Jan 16, 2011
    #20
    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. Zhenhuan Du
    Replies:
    12
    Views:
    456
    CBFalconer
    Dec 17, 2006
  2. ciccio
    Replies:
    4
    Views:
    471
    ciccio
    Jan 18, 2008
  3. charles cashion

    css conflict (or html conflict)

    charles cashion, Feb 18, 2009, in forum: HTML
    Replies:
    2
    Views:
    805
    charles cashion
    Feb 18, 2009
  4. Alessandro [AkiRoss] Re
    Replies:
    3
    Views:
    453
    Michael Doubez
    May 13, 2009
  5. Joel VanderWerf

    conflict between soap4r gem and stdlib

    Joel VanderWerf, Jun 6, 2008, in forum: Ruby
    Replies:
    1
    Views:
    137
    Eric Hodel
    Jun 6, 2008
Loading...

Share This Page