custom printf() function

[sam_cit]

Hi Everyone,

I have the following custom printf() function in the my program unit
and when i execute the program, the actual printf() function is invoked
and i get no error, no warning. However when i rename printf to printf1
in the following program unit, it invokes my custom function... what
makes this happen?

int printf(char* p,int a)
{
return(0);
}

int main()
{
struct sample
{
int a;
}a,*b;
b = &a;
b->a = 5;
++(*b).a;
printf("%d\n",b->a);
}

[Kenny McCormack]

In article <11**********************@38g2000cwa.googlegroups. com>,
<sa*****@yahoo.co.inwrote:

>Hi Everyone,

I have the following custom printf() function in the my program unit
and when i execute the program, the actual printf() function is invoked
and i get no error, no warning. However when i rename printf to printf1
in the following program unit, it invokes my custom function... what
makes this happen?

int printf(char* p,int a)
{

puts("Here we are"); /* Add this line */

> return(0);
}

int main()
{
struct sample
{
int a;
}a,*b;
b = &a;
b->a = 5;
++(*b).a;
printf("%d\n",b->a);
}

The droids will tell you that you can't invade the implementation name
space, and that, alas, printf is in that name space.

When I took your program and added the line shown above, gcc compiled it
and ran it OK (but, quite correctly, generated the following warning:

x.c:2: warning: conflicting types for built-in function `printf'

But it will work correctly on most implementations anyway.

[sam_cit]

When I took your program and added the line shown above, gcc compiled it

and ran it OK (but, quite correctly, generated the following warning:

x.c:2: warning: conflicting types for built-in function `printf'

But it will work correctly on most implementations anyway.

What exactly do you mean by correctly? are you saying it would invoke
the actual printf() function or the the customized printf() function?

[websnarf]

[e-mail] wrote:

When I took your program and added the line shown above, gcc compiled it
and ran it OK (but, quite correctly, generated the following warning:

x.c:2: warning: conflicting types for built-in function `printf'

But it will work correctly on most implementations anyway.

What exactly do you mean by correctly? are you saying it would invoke
the actual printf() function or the the customized printf() function?

I think it typically depends on the compiler and mode it is compiled
in. For example, some compilers generate "in-line" calls for built-in,
and standard library functions, depending on the flags it is given.
Because you can always compile modules seperately, there is no way for
the compiler to know that you have overridden a built-in function until
after it has emitted its code. Most compilers will nevertheless take
your overridden definition so long as you make sure the flags its given
tell it not to generate inline code for intrinsics.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

sa*****@yahoo.co.in said:

Hi Everyone,

I have the following custom printf() function in the my program unit
and when i execute the program, the actual printf() function is invoked
and i get no error, no warning. However when i rename printf to printf1
in the following program unit, it invokes my custom function... what
makes this happen?

Undefined behaviour makes this (or something else, or nothing) happen.

If you stick to the rules, so does C. If you break the rules, C is free to
break them too. You don't want that to happen.

Key learning point: Don't Break The Rules.

One of the rules is: don't tread on the implementation.

Naming a function 'printf' constitutes treading on the implementation.

So Don't Do That.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

sa*****@yahoo.co.in writes:

>When I took your program and added the line shown above, gcc compiled it
and ran it OK (but, quite correctly, generated the following warning:

x.c:2: warning: conflicting types for built-in function `printf'

But it will work correctly on most implementations anyway.

What exactly do you mean by correctly? are you saying it would invoke
the actual printf() function or the the customized printf() function?

Neither behavior is either correct or incorrect.

The standard says:

All identifiers with external linkage in any of the following
subclauses (including the future library directions) are always
reserved for use as identifiers with external linkage.

The phrase "the following subclauses" refers to the descriptions of
the standard headers, including <stdio.hwhich declares printf().

You *could* declare your printf as static.

Or, better yet, don't try to use the name "printf" for anything other
than the standard function of that name, unless your goal is to
confuse anyone reading your code.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
the totally psychotic Keith Thompson <ks***@mib.orgwrote:

>sa*****@yahoo.co.in writes:

>>When I took your program and added the line shown above, gcc compiled it
and ran it OK (but, quite correctly, generated the following warning:

x.c:2: warning: conflicting types for built-in function `printf'

But it will work correctly on most implementations anyway.

What exactly do you mean by correctly? are you saying it would invoke
the actual printf() function or the the customized printf() function?

Neither behavior is either correct or incorrect.

I think I already granted (in the part you snipped, as they say) that
the droids (that's you, in case you're wondering) would say that it is
undefined, blah, blah, blah.

[Franchie]

On Jan 14, 12:30 am, [e-mail] (Kenny McCormack)
wrote:

x.c:2: warning: conflicting types for built-in function `printf'

or perhaps more simply, use a #define:

int custom_printf(char *in, ...) {XXX}
#define printf custom_printf

This way, there will be no 'conflicting types', and there will never be
any doubt as to which function is called, and it will look exactly like
the 'normal' printf...
You can then choose to enable it or not without having to change your
code, etc.

F.

[santosh]

Franchie wrote:

On Jan 14, 12:30 am, [e-mail] (Kenny McCormack)
wrote:

x.c:2: warning: conflicting types for built-in function `printf'

or perhaps more simply, use a #define:

int custom_printf(char *in, ...) {XXX}
#define printf custom_printf

This way, there will be no 'conflicting types', and there will never be
any doubt as to which function is called, and it will look exactly like
the 'normal' printf...
You can then choose to enable it or not without having to change your
code, etc.

F.

Your attribution is incorrect. "Kenny McCormack" did not write what
you've attributed to him above.

[Franchie]

On Jan 14, 7:01 pm, "santosh" <[e-mail]:

Franchie wrote:

On Jan 14, 12:30 am, [e-mail] (Kenny McCormack)
wrote:

x.c:2: warning: conflicting types for built-in function `printf'

<...>
Your attribution is incorrect. "Kenny McCormack" did not write what
you've attributed to him above.

First came up here:
http://groups-beta.google.com/group/...9953d8ed2e2827
But you're right, I forgot to change the post date, and put in
excessive indentation, so all my apologies.

Disclaimer: I did not intend this quote as a statement. Simply, it was
the result of the compilation of using duplicate printfs, and seemed an
appropriate starting-point for the post. No comment intended, I hope no
offense taken.

F.

[Kenny McCormack]

In article <11**********************@v45g2000cwv.googlegroups .com>,
Franchie <Fr******************@gmail.comwrote:

>On Jan 14, 12:30 am, [e-mail] (Kenny McCormack)
wrote:

> x.c:2: warning: conflicting types for built-in function `printf'

or perhaps more simply, use a #define:

int custom_printf(char *in, ...) {XXX}
#define printf custom_printf

This way, there will be no 'conflicting types', and there will never be
any doubt as to which function is called, and it will look exactly like
the 'normal' printf...
You can then choose to enable it or not without having to change your
code, etc.

F.

Yes, but that's not the point. The point is to seek knowledge,
something that is actively discouraged by the droids of this group.

[Kenny McCormack]

In article <11*********************@51g2000cwl.googlegroups.c om>,
Franchie <Fr******************@gmail.comwrote:
....

>Disclaimer: I did not intend this quote as a statement. Simply, it was
the result of the compilation of using duplicate printfs, and seemed an
appropriate starting-point for the post. No comment intended, I hope no
offense taken.

Don't worry about it. Anyone with two brain cells to run together could
figure it out.

Admittedly, that lets out most of the droids of this ng, but, really,
when you get down to it, do you care about those fuckwits?

[Franchie]

On Jan 14, 8:38 pm, [e-mail] (Kenny McCormack)
wrote:

In article <[e-mail] .com>,
Yes, but that's not the point. The point is to seek knowledge,
something that is actively discouraged by the droids of this group.

Lol, for the sake of longevity, I will attempt to stay neutral on the
subject of droids ;-)

But back to the knowledge part... As I understand, the problem is due
to the compiler linking the default c library, etc...
Is there a standard way of explicitly preventing that? I seem to recall
that the oskit project recoded an entire subset (ie: some bits from :-)
the c library so that it had no external dependencies, and linked that
instead of the default link library... They did that with a gcc
extension if I recall correctly, but is this standard practice?

[santosh]

Franchie wrote:

On Jan 14, 8:38 pm, [e-mail] (Kenny McCormack)
wrote:

In article <[e-mail] .com>,
Yes, but that's not the point. The point is to seek knowledge,
something that is actively discouraged by the droids of this group.

Lol, for the sake of longevity, I will attempt to stay neutral on the
subject of droids ;-)

But back to the knowledge part... As I understand, the problem is due
to the compiler linking the default c library, etc...
Is there a standard way of explicitly preventing that?

Not unless you take control of the linking step.

I seem to recall
that the oskit project recoded an entire subset (ie: some bits from :-)
the c library so that it had no external dependencies, and linked that
instead of the default link library... They did that with a gcc
extension if I recall correctly, but is this standard practice?

Yes. IIRC the --nodefaultlibs, --nostdlib and --nostartfiles switches
do this. But these are all non-standard and vary with implementations.

[Randy Howard]

On Sun, 14 Jan 2007 13:50:53 -0600, Franchie wrote
(in article <11**********************@s34g2000cwa.googlegroups .com>):

On Jan 14, 8:38 pm, [e-mail] (Kenny McCormack)
wrote:

>In article <[e-mail] .com>,
Yes, but that's not the point. The point is to seek knowledge,
something that is actively discouraged by the droids of this group.

Lol, for the sake of longevity, I will attempt to stay neutral on the
subject of droids ;-)

A wise policy.

But back to the knowledge part... As I understand, the problem is due
to the compiler linking the default c library, etc...

It's not really a "problem", it's expected behavior.

Is there a standard way of explicitly preventing that?

A better question might be, is it normal for people to try and provide
different behavior for a function name that is part of standard C, when
they can easily implement anything they want by using a different name,
such as perhaps "xprintf()", and then do whatever they like, without
having to jump through hoops?
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Old Wolf]

Kenny McCormack wrote:

<sa*****@yahoo.co.inwrote:

I have the following custom printf() function in the my program unit
and when i execute the program, the actual printf() function is invoked
and i get no error, no warning. rintf is in that name space.

When I took your program and added the line shown above, gcc compiled it
and ran it OK

But it will work correctly on most implementations anyway.

Obviously it doesn't work "correctly" on the OP's implementation ,
so that wasn't a very useful answer on your part.

[Old Wolf]

Richard Heathfield wrote:

Naming a function 'printf' constitutes treading on the implementation.

Not if the function has internal linkage, and stdio.h is not included

[pete]

Old Wolf wrote:

>
Richard Heathfield wrote:

Naming a function 'printf'
constitutes treading on the implementation.

Not if the function has internal linkage, and stdio.h is not included

printf has external linkage
and it doesn't matter whether or not stdio.h has been included.
The standard says "always reserved".
N869
7.1.3 Reserved identifiers

-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.

--
pete

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

pete wrote:

Old Wolf wrote:

Richard Heathfield wrote:

Naming a function 'printf'
constitutes treading on the implementation.

Not if the function has internal linkage, and stdio.h is not included

printf has external linkage

The standard library function printf has external linkage.

and it doesn't matter whether or not stdio.h has been included.
The standard says "always reserved".
N869
7.1.3 Reserved identifiers

-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.

"always reserved for use as identifiers with external linkage", not
"always reserved for any use"

This is a strictly conforming program:

/* no stdio.h */

static int printf(void)
{
return 0;
}

int main(void)
{
return printf();
}

[pete]

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?= wrote:

>
pete wrote:

Old Wolf wrote:

>
Richard Heathfield wrote:
Naming a function 'printf'
constitutes treading on the implementation.
>
Not if the function has internal linkage, and stdio.h is not included

printf has external linkage

The standard library function printf has external linkage.

and it doesn't matter whether or not stdio.h has been included.
The standard says "always reserved".
N869
7.1.3 Reserved identifiers

-- All identifiers with external linkage in any of the
following subclauses (including the future library
directions) are always reserved for use as identifiers
with external linkage.

"always reserved for use as identifiers with external linkage", not
"always reserved for any use"

This is a strictly conforming program:

/* no stdio.h */

static int printf(void)
{
return 0;
}

int main(void)
{
return printf();
}

Thanks.

--
pete