calling my custom function same as library function

[infobahn]

:BTW, it is in your power to eliminate one more minor but annoying
:instance of rudeness - your use of an unorthodox quote character.

Sorry, which RFC is it that defines the Usenet quote character?

Be nice. He didn't say that : is "non-standard" (implying a de jure
standard). He said that it's "unorthodox", which it is. Most people
use > rather than : and so > is "orthodox" and : is "unorthodox".
Having said that, he does seem to be using the word "unorthodox" in
a way that doesn't entirely coincide with my dictionary definition.
It is therefore an unorthodox use of the word "unorthodox" (and I
myself am using "unorthodox" in an unorthodox manner, recursively!).

Nevertheless, his - and my - use of "unorthodox" certainly has the
saving grace that it is commonplace; the dictionary inevitably lags
behind modern usage, and "unorthodox" has already acquired in common
parlance the meaning which Mr Balmer appeared to intend. Therefore
his unorthodox use of "unorthodox" isn't quite as unorthodox now as
it would have been considered many years ago. It has become orthodox.

Or something.

In any case, it would make newsreader writers' jobs much easier if
there /were/ a Usenet standard for quoting, and > is as close as
we're going to get to a standard, so it makes sense to use it.

ObC: imagine you're writing a C program to re-flow Usenet text
to keep your reply (and the text which it quotes) within N
columns, whilst correctly retaining attributions and associating
them with the correct text. Can you devise a mechanism for
automatically identifying which characters at the beginning of
a line should be regarded as quote characters?

(10 marks. Write on only one side of the newsgroup. No copying.)

 

[Lawrence Kirby]

:Let's suppose you decide to replace malloc()

A standard which prohibits you from doing so will be often
violated, of necessity.

The standard doesn't prohibit you from doing this, it simply ceases to
make any guarantees about the behaviour of your program if you do. It
doesn't guarantee that an implementation will allow you to do this. For
example trying to replace memcpy() would be tricky with many
implementations that (legitimately) generate inline code for it rather
than a library call.

The purpose of standardizing functions is not to lock the user
in and prohibit them from using other implimentations.

It is better to look at this from a different angle. If you want to change
the implementation then fine, but keep that change separate from your user
program code. You program can keep to the standard but you separately take
on the responsibility of an implementor to maintain a valid
implementation. Of course if you break it that's your problem, not the
problem of those who wrote the implementation originally.

: However, all this speculation about mechanisms is beside the
oint, which is that the C Standard forbids the programmer from
:using any of the library function names for his own externally-
:linked objects and functions.

I will review the exact wording of the standard at my earliest
opportunity. The portions that have been quoted here did not contain
such a prohibition.

The standard has a set of rules and specifies the behaviour of programs
that stick to them. If your program doesn't the standard can't be used to
predict what your program will do.

Lawrence

 

[Deniz Bahar]

According to the C standard, it is neither portable nor acceptable to
use the name of a library function in a context where it has external
linkage.

That means, you can define a function named "atof" if and only if you
define it with the static keyword, which means you can only call it by
name from within the same source file.

Otherwise you generate undefined behavior.

Do you think it is advisable for me to make a header
(mylibraryreplacements.h) and have static definitions in them and
include them in the source files that need it?

Like:

mylibraryreplacements.h
=======================
#ifndef _MYLIBRARYREPLACEMENTS_H
#define _MYLIBRARYREPLACEMENTS_H

static double atof(char *){/*body*/}
static int atoi(char *){/*body*/}
static void* malloc(size_t size){/*body*/}

#endif



Is this a "poor" technique?

 

[Gordon Burditt]

Do you think it is advisable for me to make a header

(mylibraryreplacements.h) and have static definitions in them and
include them in the source files that need it?

I think it would be an extremely bad idea to do this for functions
that need static or global data which OUGHT TO be shared but won't be.
atof() and atoi(), fine, except you will have multiple copies of
the code in your executables.

malloc(), *NOT FINE*. You didn't include a matching free() in
there. Expect all heck to break loose when you try to free()
something allocated from a different pool than it was originally
malloc()ed from. This is a problem even if you were careful to
ensure that every piece of your program that uses malloc() includes
your header file.

Like:

mylibraryreplacements.h
=======================
#ifndef _MYLIBRARYREPLACEMENTS_H
#define _MYLIBRARYREPLACEMENTS_H

static double atof(char *){/*body*/}
static int atoi(char *){/*body*/}
static void* malloc(size_t size){/*body*/}

#endif



Is this a "poor" technique?

You end up with multiple copies of code, unnecessarily. There are
lots of potential problems when each copy of malloc() is using its
own pool of memory and someone free()s using a different instance
of malloc() than what it was allocated with.

Gordon L. Burditt