redefine a function with a same name

[paytam]

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

[Richard Heathfield]

pa****@gmail.com said:

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

Want something else instead. Redefining standard library functions is a bad
idea.

But if you just want to be able to use a different name for it, that's fine.
Just do something like this:

#include <stdio.h>

#define paytamTriesToGetACharFromStdin getchar

int main(void)
{
int ch = 0;
while((ch = paytamTriesToGetACharFromStdin()) != EOF)
{
putchar(ch);
}
return 0;
}
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Bos]

pa****@gmail.com wrote:

I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

You should ask in a newsgroup dedicated to your particular compiler
suite, since in the general case the ISO C Standard declares this to
cause undefined behaviour.

Richard

[rrs.matrix]

pa****@gmail.com wrote:

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

open the header file stdio.h - /usr/include/stdio.h and change it to
whatever u want.
done.

[Chris Dollin]

pa****@gmail.com wrote:

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

Something else.

[You can't do so portably, implementation-specific techniques are implementation
specific and generally offtopical, and you haven't explained why you want to
pull the rug out from under your victims' feet.]

--
Chris "look! a unicorn! (fx:hack) I mean /horse/, sorry!" Dollin
"Who are you? What do you want?" /Babylon 5/

[Chris Dollin]

rr********@gmail.com wrote:

pa****@gmail.com wrote:

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

open the header file stdio.h - /usr/include/stdio.h and change it to
whatever u want.
done.

You will be.

First, editing the header file doesn't redefine any functions, always
supposing you can do it.

Second, if the OP is J Random Unix User, they won't be able to edit
/usr/include/stdio.h, because they won't have permission to do so.

Third, if the OP is J Random RISC OS User, there /isn't/ a file
called /usr/include/stdio.h, there isn't a directory called
/usr/include, there isn't a directory called /usr, and there isn't
a directory called /.

Fourth, in any case the standard includes need not be "files" /at
all/, so there may be nothing to edit except the compiler
executable. The term "playing with fire" doesn't begin to cover
it.

Finally, even if you /can/ do any of this, it's very likely you
shouldn't. `getchar` is supposed to do what `getchar` is supposed
to do - and people use it to do that.

--
Chris "making 'finally' topical on c.l.c" Dollin
"Who are you? What do you want?" /Babylon 5/

[CBFalconer]

rr********@gmail.com wrote:

pa****@gmail.com wrote:

I want to redefine a function getchar() in header stdio.h ,but I
don't know what should I do.

open the header file stdio.h - /usr/include/stdio.h and change it
to whatever u want.

This has to be one of the most imbecelic (and wrong) replies ever
seen in c.l.c, not to mention the childish use of 'u'.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

[Richard Bos]

Chris Dollin <ch**********@hp.com> wrote:

rr********@gmail.com wrote:

open the header file stdio.h - /usr/include/stdio.h and change it to
whatever u want.
done.

You will be.

First, editing the header file doesn't redefine any functions, always
supposing you can do it.

Second, if the OP is J Random Unix User, they won't be able to edit
/usr/include/stdio.h, because they won't have permission to do so.

Third, if the OP is J Random RISC OS User, there /isn't/ a file
called /usr/include/stdio.h, there isn't a directory called
/usr/include, there isn't a directory called /usr, and there isn't
a directory called /.

Fourth, in any case the standard includes need not be "files" /at
all/, so there may be nothing to edit except the compiler
executable. The term "playing with fire" doesn't begin to cover
it.

Fifth, if you try to do this on a multi-user system the sysadmin will
start withdrawing your privileges with extreme prejudice. Try doing it
twice and the privileges withdrawn may well include the right to draw
breath.

Richard

[goose]

CBFalconer wrote:

rr********@gmail.com wrote:

pa****@gmail.com wrote:

I want to redefine a function getchar() in header stdio.h ,but I
don't know what should I do.

open the header file stdio.h - /usr/include/stdio.h and change it
to whatever u want.

This has to be one of the most imbecelic (and wrong) replies ever
seen in c.l.c,

Maybe so, but many have considered some of *my* postings a
worthy contender for that hotly contested title :-)

Anyway, what's the accepted wisdom about doing the following?
(Is it at least well defined?)

-------------
#include <stdio.h>

int mygetchar (void)
{
printf ("My getchar\n");
return getchar();
}

#define getchar() mygetchar()

int main (void)
{
char c = getchar ();
printf ("got char '%c'\n", c);
return 0;
}

-------------
goose

[Andrew Poelstra]

On 2006-06-23, goose <ru**@webmail.co.za> wrote:

CBFalconer wrote:

rr********@gmail.com wrote:

> pa****@gmail.com wrote:
>>
>> I want to redefine a function getchar() in header stdio.h ,but I
>> don't know what should I do.
>
> open the header file stdio.h - /usr/include/stdio.h and change it
> to whatever u want.

This has to be one of the most imbecelic (and wrong) replies ever
seen in c.l.c,

Maybe so, but many have considered some of *my* postings a
worthy contender for that hotly contested title :-)

Anyway, what's the accepted wisdom about doing the following?
(Is it at least well defined?)

-------------
#include <stdio.h>

int mygetchar (void)
{
printf ("My getchar\n");
return getchar();
}

#define getchar() mygetchar()

int main (void)
{
char c = getchar ();
printf ("got char '%c'\n", c);
return 0;
}

-------------

(Should be "#define getchar mygetchar" without the parentheses).

It's well-defined, because after your #define, all instances of getchar
will be replaced with mygetchar. Since there ins't anything called
'mygetchar' in stdio.h, there won't be any name conflicts at all. The
preprocessor will wash away the text 'getchar', meaning no conflicts
there, either.

Whether it's a wise thing to do is questionable. It actually seems like
a good idea in some debugging cases. (For example, redefining malloc to
print a message to stdout about how much memory is allocated or when).
I can't think of why it would be used in production code, though.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[goose]

Andrew Poelstra wrote:

On 2006-06-23, goose <ru**@webmail.co.za> wrote:
<snipped>

#define getchar() mygetchar()

int main (void)
{
char c = getchar ();
printf ("got char '%c'\n", c);
return 0;
}

-------------

(Should be "#define getchar mygetchar" without the parentheses).

Well, either should be okay (can't test it right now, no compiler
handy) with the only difference being a matter of taste. I'd rather
leave the () in 'cos then a simple scanning of the #define tells
me that its used "just like a function call" further on.

<snipped>
Whether it's a wise thing to do is questionable.

We-ell ... the OP asked a very unwise thing to do anyway, one
can only hope it is because he wants to put it to a /wise/
use, and not willy-nilly trample all over the standard library.

goose,

[CBFalconer]

goose wrote:

.... snip ...
Anyway, what's the accepted wisdom about doing the following?
(Is it at least well defined?)

-------------
#include <stdio.h>

int mygetchar (void)
{
printf ("My getchar\n");
return getchar();
}

#define getchar() mygetchar()

int main (void)
{
char c = getchar ();
printf ("got char '%c'\n", c);
return 0;
}

Strictly speaking it is UB. redefining entries in the standard
library that have been referenced via the appropriate headers is
not allowed.

In practice, this particular one MAY work. No guarantees.

I take it back. It will work, because you never use the define.
Now think about why I said that.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

[goose]

CBFalconer wrote:

goose wrote:

... snip ...

Anyway, what's the accepted wisdom about doing the following?
(Is it at least well defined?)

-------------
#include <stdio.h>

int mygetchar (void)
{
printf ("My getchar\n");
return getchar();
}

#define getchar() mygetchar()

int main (void)
{
char c = getchar ();
printf ("got char '%c'\n", c);
return 0;
}

Strictly speaking it is UB. redefining entries in the standard
library that have been referenced via the appropriate headers is
not allowed.

Hm? getchar (the #define) and getchar (the function prototype)
don't necessarily step on each others toes, right? Or does
"redefining" above mean "cannot reuse any symbols declared
in the standard headers whether said symbols are prototype,
#defines or typedefs?

In practice, this particular one MAY work. No guarantees.
Never is with UB.

I take it back. It will work, because you never use the define.
Now think about why I said that.

I did. I'm afraid I miss the point; AFAICT, getchar (the #define)
should get text-substituted with mygetchar. I'd be happy to hear
why that won't happen (Are we talking recursive mygetchar() bomb?
thats simple enough to fix by replacing
getchar ();
in mygetchar with
(getchar) ();
although the @define follows the use of the function getchar()).

goose

[CBFalconer]

goose wrote:

CBFalconer wrote:

.... snip ...

I take it back. It will work, because you never use the define.
Now think about why I said that.

I did. I'm afraid I miss the point; AFAICT, getchar (the #define)
should get text-substituted with mygetchar. I'd be happy to hear
why that won't happen (Are we talking recursive mygetchar() bomb?
thats simple enough to fix by replacing
getchar ();
in mygetchar with
(getchar) ();
although the @define follows the use of the function getchar()).

You defined a functional macro with getchar(). You never used it,
because the subsequent occurance of getchar was followed by a
blank.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

goose wrote:

CBFalconer wrote:

... snip ...

I take it back. It will work, because you never use the define.
Now think about why I said that.

I did. I'm afraid I miss the point; AFAICT, getchar (the #define)
should get text-substituted with mygetchar. I'd be happy to hear
why that won't happen (Are we talking recursive mygetchar() bomb?
thats simple enough to fix by replacing
getchar ();
in mygetchar with
(getchar) ();
although the @define follows the use of the function getchar()).

You defined a functional macro with getchar(). You never used it,
because the subsequent occurance of getchar was followed by a
blank.

Nope.

For a function-like macro, the left parenthesis must immediately
follow the macro name (with no intervening whitespace) *in the macro
definition*. In an invocation, the left parenthesis merely has to be
the next preprocessing token.

The whole point of a function-like macro is that it can be invoked as
if it were an actual function. Disallowing whitespace in an
invocation would have broken that.

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

[Keith Thompson]

Andrew Poelstra <ap*******@localhost.localdomain> writes:

On 2006-06-23, goose <ru**@webmail.co.za> wrote: [snip]

int mygetchar (void)
{
printf ("My getchar\n");
return getchar();
}

#define getchar() mygetchar()

[snip]
(Should be "#define getchar mygetchar" without the parentheses).

Not necessarily. With the parentheses it defines a function-like
macro; you can then bypass the macro definition (and call the actual
getchar() function) by enclosing the name in parentheses:

(getchar)()

With "#define getchar mygetchar", you can't do that. It depends on
whether you want to allow the macro to be bypassed.

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

[Morris Dovey]

Richard Bos (in 44*****************@news.xs4all.nl) said:

| pa****@gmail.com wrote:
|
|| I want to redefine a function getchar() in header stdio.h ,but I
|| don't know what should I do.
|
| You should ask in a newsgroup dedicated to your particular compiler
| suite, since in the general case the ISO C Standard declares this to
| cause undefined behaviour.

[ Original post never showed up at my server ]

You can portably redefine standard library function invocations; but
shouldn't tamper with the standard header files.

At the link below is an example where calloc(), malloc(), realloc(),
and free() have been redefined in a in order to produce a debug
trace - but note that stdlib.h hasn't been touched.

The file is the concatenation of two translation units, each of which
is preceeded by a descriptive prolog.

A lot of people have downloaded the code; and there haven't been any
problems reported in the past six years, so I'll guess that there
haven't been any portability issues.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/mrd/c/mtrace.c

[Andrew Poelstra]

On 2006-06-23, goose <ru**@webmail.co.za> wrote:

Andrew Poelstra wrote:

On 2006-06-23, goose <ru**@webmail.co.za> wrote:
<snipped>

>
> #define getchar() mygetchar()
>
> int main (void)
> {
> char c = getchar ();
> printf ("got char '%c'\n", c);
> return 0;
> }
>
> -------------
>

(Should be "#define getchar mygetchar" without the parentheses).

Well, either should be okay (can't test it right now, no compiler
handy) with the only difference being a matter of taste. I'd rather
leave the () in 'cos then a simple scanning of the #define tells
me that its used "just like a function call" further on.

It would be easier to read, but if you accidentally put a space in
there, getchar will be replaced with "() mygetchar()" instead of just
"mygetchar()".
<snipped>

Whether it's a wise thing to do is questionable.

We-ell ... the OP asked a very unwise thing to do anyway, one
can only hope it is because he wants to put it to a /wise/
use, and not willy-nilly trample all over the standard library.

Well, if he does abuse my advice, he won't be very employable, and
it'll all eventually work itself out.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Keith Thompson]

Andrew Poelstra <ap*******@localhost.localdomain> writes:

On 2006-06-23, goose <ru**@webmail.co.za> wrote:

Andrew Poelstra wrote:

On 2006-06-23, goose <ru**@webmail.co.za> wrote:

<snipped>

>
> #define getchar() mygetchar()
>
> int main (void)
> {
> char c = getchar ();
> printf ("got char '%c'\n", c);
> return 0;
> }
>
> -------------
>

(Should be "#define getchar mygetchar" without the parentheses).

Well, either should be okay (can't test it right now, no compiler
handy) with the only difference being a matter of taste. I'd rather
leave the () in 'cos then a simple scanning of the #define tells
me that its used "just like a function call" further on.

It would be easier to read, but if you accidentally put a space in
there, getchar will be replaced with "() mygetchar()" instead of just
"mygetchar()".

So don't put a space in there (in the macro definition, that is). In
a function-like macro definition, the '(' must immediately follow the
macro name, with no whitespace (one of the few cases where whitespace
between tokens is significant). Anyone who writes macros had better
know that.

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

[Herbert Rosenau]

On Fri, 23 Jun 2006 15:36:50 UTC, Andrew Poelstra
<ap*******@localhost.localdomain> wrote:

Whether it's a wise thing to do is questionable. It actually seems like
a good idea in some debugging cases. (For example, redefining malloc to
print a message to stdout about how much memory is allocated or when).
I can't think of why it would be used in production code, though.

Come on and write a parser that needs to ungetc() more than the one
single char that ungetc() allows.

For performance you would simple getc() until you knows that the last
2, 3, 4 chars were gotten too much - so ungetc() them simple to reset
the input stream to a well known state, change the state of your state
mashine to the right value and try again.

myungetc() - ungets in an extended unget buffer
hide the buffer from the rest of the application
mygetc() - read from the extended unget buffer until it is emty,
then from the stream further using the real getc()

#define mygetc getc
#define ungetc ungetc

on the right place and you can adopt sorce code already written
without the need to change each and any occurence of getc() and
ungetc().

Make things so simple as possible. Document your work right.

I see no need for (f)gets() and other functions on a time where
punchcards out of order. I can't even read text files when I don't
know ith they are ordinated by DOS, WinDos, OS/2, Linux, AIX, SINIX,
HPUX, /390, MAC or whatever ttransfered without any try to transform
to your systems native text format. Transformchapters (readed as line
of up 1 MB in size to lines of 80 char max, separate true chapters
with really empty lines (\n) only, reformat tables (plain text format)
to something readable,........

getc() in cooperation with an extended ungetc() is the most possible
solution in runtime and resource usage.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Joe Wright]

pa****@gmail.com wrote:

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

Hi yourself. Try again to explain what you want to accomplish. The
function getchar() is defined in libc or whatever. It is only described
(protoyped) in stdio.h.

You can't 'redefine' a library function. What you can do is write
(define) your own function and then lie like hell so that ..

c = getchar();

... will actually call your function instead of the standard one. Is this
what you want to do?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Bos]

"Morris Dovey" <mr*****@iedu.com> wrote:

Richard Bos (in 44*****************@news.xs4all.nl) said:

| pa****@gmail.com wrote:
|
|| I want to redefine a function getchar() in header stdio.h ,but I
|| don't know what should I do.
|
| You should ask in a newsgroup dedicated to your particular compiler
| suite, since in the general case the ISO C Standard declares this to
| cause undefined behaviour.

[ Original post never showed up at my server ]

You can portably redefine standard library function invocations; but
shouldn't tamper with the standard header files.

At the link below is an example where calloc(), malloc(), realloc(),
and free() have been redefined in a in order to produce a debug
trace - but note that stdlib.h hasn't been touched.

From n1124, 7.1.3#1 - emphasis mine:

# — Each identifier with file scope listed in any of the following
# subclauses (including the future library directions) is reserved for
# use _as_a_macro_name_ and as an identifier with file scope in the
# same name space if any of its associated headers is included.

and #3:

# 3 If the program removes (with #undef) any macro definition of an
# identifier in the first group listed above, the behavior is
# undefined.

So yes, it's undefined behaviour. It's not very likely to cause real
problems anywhere, but it's not defined.

Richard

[Morris Dovey]

Richard Bos (in 44****************@news.xs4all.nl) said:

| From n1124, 7.1.3#1 - emphasis mine:
|
| #  Each identifier with file scope listed in any of the following
| # subclauses (including the future library directions) is
| reserved for # use _as_a_macro_name_ and as an identifier with
| file scope in the # same name space if any of its associated
| headers is included.
|
| and #3:
|
| # 3 If the program removes (with #undef) any macro definition of an
| # identifier in the first group listed above, the behavior is
| # undefined.
|
| So yes, it's undefined behaviour. It's not very likely to cause real
| problems anywhere, but it's not defined.

Good catch! I missed that one - and although I haven't heard of it
causing problems for anyone (which is what you expected), I should at
least add a warning to the prologs that the #undef's may produce
undefined behavior on some systems.

Thanks!

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

[Tom Rauschenbach]

On Fri, 23 Jun 2006 09:39:58 +0100, Chris Dollin wrote:

rr********@gmail.com wrote:

pa****@gmail.com wrote:

hi all
I want to redefine a function getchar() in header stdio.h ,but I don't
know what should I do.

open the header file stdio.h - /usr/include/stdio.h and change it to
whatever u want.
done.

You will be.

First, editing the header file doesn't redefine any functions, always
supposing you can do it.

Second, if the OP is J Random Unix User, they won't be able to edit
/usr/include/stdio.h, because they won't have permission to do so.

Third, if the OP is J Random RISC OS User, there /isn't/ a file
called /usr/include/stdio.h, there isn't a directory called
/usr/include, there isn't a directory called /usr, and there isn't
a directory called /.

Fourth, in any case the standard includes need not be "files" /at
all/, so there may be nothing to edit except the compiler
executable. The term "playing with fire" doesn't begin to cover
it.

Finally, even if you /can/ do any of this, it's very likely you
shouldn't. `getchar` is supposed to do what `getchar` is supposed
to do - and people use it to do that.

Isn't this really a question about the link editor ? It sounds to me like
the OP wants to replace a standard library function with his own. Very
little to do with C, I think.

[Dave Thompson]

On 23 Jun 2006 07:42:55 -0700, "goose" <ru**@webmail.co.zawrote:

Anyway, what's the accepted wisdom about doing the following?
(Is it at least well defined?)

-------------
#include <stdio.h>

int mygetchar (void)
{
printf ("My getchar\n");
return getchar();
}

#define getchar() mygetchar()

All standard library functions can be #define'd as function-like
macros by the header that declares (prototypes) them, and getchar() in
particular pretty commonly is. It is a constraint violation and a
required diagnostic to re-#define an existing macro differently.
You need to #undef getchar first. Note that you don't need to put it
in #ifdef to be safe -- #undef of a nonmacro is a guaranteed no-op.

Given you do that, it should as you want go through your replacement.
7.1.3p1 does say it is 'reserved for use as a macro name' without
mentioning #undef, but p3 says that #undef of _[A-Z_]* gives U.B.
without saying the same for any other standard-reserved identifiers,
and 7.1.4p1 says that #undef of such a 'shadow' macro will allow
access to the real function; it doesn't make sense to do that without
also allowing you to #define it for your own use.

Note however that (other) <stdio.hshadow macros could legally use
each other, including getchar() expecting to get the standard one, and
get your replacement instead. For just a wrapper like this it should
still work, but if you try to rewrite a std lib function to do
something different (and IYO better) you are courting trouble.

Whether this sort of thing is _wise_ is a whole other question.
Personally I would rather use a debugger in most cases where this
might possibly be of any use. And in the cases where a debugger
doesn't work, printf (or more generally stdout) may not be the right
answer. But that just opens up _barrels_ of worms.

int main (void)
{
char c = getchar ();
printf ("got char '%c'\n", c);
return 0;
}

<pedanticplain char may be signed and unable to correctly represent
some values returned from getchar(), including EOF, even when
converted back to unsigned char by %c inside *printf. In most cases
including this use int. But I'm sure that wasn't your point.
- David.Thompson1 at worldnet.att.net

[Dave Thompson]

On Mon, 26 Jun 2006 06:40:45 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

"Morris Dovey" <mr*****@iedu.comwrote:

Richard Bos (in 44*****************@news.xs4all.nl) said:

<snip>

You can portably redefine standard library function invocations; but
shouldn't tamper with the standard header files.

<snip>

From n1124, 7.1.3#1 - emphasis mine:

# — Each identifier with file scope listed in any of the following
# subclauses (including the future library directions) is reserved for
# use _as_a_macro_name_ and as an identifier with file scope in the
# same name space if any of its associated headers is included.

and #3:

# 3 If the program removes (with #undef) any macro definition of an
# identifier in the first group listed above, the behavior is
# undefined.

So yes, it's undefined behaviour. It's not very likely to cause real
problems anywhere, but it's not defined.

I believe 'first group above' means the first dash item in p1: "All
identifiers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use."

getchar(), and most other std-lib functions (except _Exit and maybe
another I've forgotten), do not fall into this group; they are in the
item you quoted, which is the fifth.

7.1.4p1 explicitly promises you can 'bypass' a shadowing macro
by using (func) (args) or by #undef, implicitly without any U.B.
Although this does not clearly promise you can re-#define it.
- David.Thompson1 at worldnet.att.net