Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > conflict function definition with stdlib.h

Reply
Thread Tools

conflict function definition with stdlib.h

 
 
Ian Collins
Guest
Posts: n/a
 
      01-16-2011
On 01/17/11 10:31 AM, Richard Sanders wrote:
>
> 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;
> }


Odds are that does nothing. A real test for conflicts would be:

int printf(const char* str );

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


Which is what I'd expect. Your linker has used your version rather than
the library version.

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


See above.

> "#undef printf" means do not link the libray version, link the
> supplied version, it has nothing to do with header files.


No, it is a NOP.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-16-2011
Richard Sanders <(E-Mail Removed)> writes:
> On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
> <(E-Mail Removed)> wrote:
>
>>On 1/16/2011 3:08 PM, Richard Sanders wrote:

[...]
>>> #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.


And if you got "12345" and I got "Hello world!", who would be right?

I get "Hello world!" with at least one implementation, and "12345" with
at least one other. Your program's behavior is undefined. Which means
that the behavior you're seeing is as valid as any other, and proves
very little.

Try this: remove the "#undef printf" and see if it makes any difference.

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


You are mistaken. "#undef" removes a macro definition; it has nothing
to do with linking.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-17-2011
On 1/16/2011 4:31 PM, Richard Sanders wrote:
> On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
> <(E-Mail Removed)> wrote:
>
>> On 1/16/2011 3:08 PM, Richard Sanders wrote:
>>> On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
>>> <(E-Mail Removed)> wrote:
>>>
>>>> On 1/16/2011 3:59 AM, Richard Sanders wrote:
>>>>> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<(E-Mail Removed)>
>>>>> 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, ...)


Try `void printf(int *foo, double bar)' here, and perhaps you'll
see what I mean. (But also see below.)

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


Since the program's behavior is undefined (7.1.3p2, also 7.19.2p2),
few useful conclusions can be drawn from it. It could have printed
"12345" or "Hello world!" or "Eat Bertha's Mussels" or done something
even stranger. The C Standard makes no guarantees or assurances about
this program; it washes its hands.

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


... meaning that it's of no help to the O.P., whose code has a
declaration that conflicts with the header's. Try the experiment
suggested above.

It's also true that <stdlib.h> has no right to declare the O.P.'s
identifier. Since it does, we conclude that the implementation is
non-conforming, so arguments that begin with "The Standard says ..."
are already suspect. The implementation is non-conforming in this
respect, and may well be non-conforming in others: we're all guessing.
Perhaps its `int' has a fractional part, who knows?

> "#undef printf" means do not link the libray version, link the
> supplied version, it has nothing to do with header files.


`#undef printf' means *only* "If there is a macro named `printf',
function-like or object-like, with any expansion whatever, remove
that macro." It means nothing at all about linkage, nothing about
versions, nothing about ownership, nothing, nothing, *nothing* else.

... in C, that is, as opposed to whatever language the O.P.'s
compiler translates.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      01-17-2011
On 1/16/2011 4:39 PM, Richard Sanders wrote:
> On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
> <(E-Mail Removed)> 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.


I *think* you're referring to part of 7.1.4p1, but your
assertion is garbled and I'm not sure. Summarizing the salient
points of that paragraph: (1) every Standard library function must
be implemented as an actual function, (2) every Standard library
function may also be implemented as a macro, (3) such a macro, if
it exists, can be suppressed or avoided.

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


This may be true of your implementation, but it is not true of
all, and not true of C-as-defined. C defines no mechanism for
replacing any part of the implementation, short of moving to a
different implementation altogether. If you (try to) supply your
own printf() or malloc() or abort(), the behavior is undefined:
You can no longer count on *anything* the Standard says, because
you have placed yourself outside the law. (7.1.3p2)

Being outside the law is not entirely bad, *if* you happen to
know the rules of the lawless territory you choose to inhabit. But
different implementations border on different regions of that lawless
land, and when you stray across a border you may find that the rules
have changed without warning.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-17-2011
Ian Collins <(E-Mail Removed)> writes:
> On 01/17/11 10:31 AM, Richard Sanders wrote:

[...]
>> "#undef printf" means do not link the libray version, link the
>> supplied version, it has nothing to do with header files.

>
> No, it is a NOP.


If the implementation defines printf() as a macro, "#undef printf" makes
the actual function declaration directly visible. But since any such
macro must behave the same way as the function, yes, it's effectively a
NOP.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Template instantiation conflict with function definition Alessandro [AkiRoss] Re C++ 3 05-13-2009 10:08 AM
css conflict (or html conflict) charles cashion HTML 2 02-18-2009 09:41 PM
conflict between friend function and inherited class function ciccio C++ 4 01-18-2008 12:13 AM
problem about sovling definition conflict when porting Zhenhuan Du C Programming 12 12-17-2006 05:17 PM
can a class definition inside another class's definition Jianli Shen C++ 1 03-13-2005 06:02 PM



Advertisments