[comp.lang.c] using standard interfaces

scs@athena.mit.edu (Steve Summit) (09/16/88)

A while back, somebody wrote (explaining why they hadn't and/or
wouldn't use a newly standardized function):

	I doubt that memcpy even existed then; and it is *not* standard
	now.  Perhaps it will be several years after the ANSI standard is
	adopted, but not till then.

The reason we keep pointing out the existence of standard
functions to those who would rather (or have to) roll their own
is to encourage people to start using the standard interface, by
writing their own function with the same name and parameters,
rather than sticking special-purpose code in-line, or inventing
some new name.  This way the program can take advantage of
standardized, optimized implementations when they become
available (for instance when the program is ported to a different
system which has them).

                                            Steve Summit
                                            scs@adam.pika.mit.edu

g-rh@cca.CCA.COM (Richard Harter) (09/16/88)

In article <7076@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:

>The reason we keep pointing out the existence of standard
>functions to those who would rather (or have to) roll their own
>is to encourage people to start using the standard interface, by
>writing their own function with the same name and parameters,
>rather than sticking special-purpose code in-line, or inventing
>some new name.  This way the program can take advantage of
>standardized, optimized implementations when they become
>available (for instance when the program is ported to a different
>system which has them).

This sounds good, but there is a problem to take into account.  If
you have your own routine with the same name as the "standard"
routine there is the potential for problems when you port into
a system that has the "standard" routine in its library.  The
problem is that the library implementers may use said routine 
internally in the library in a way that conflicts with your routine.
For example, it is quite unsafe to roll your own storage allocator
and call it malloc.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.

henry@utzoo.uucp (Henry Spencer) (09/18/88)

In article <7076@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>	I doubt that memcpy even existed then; and it is *not* standard
>	now.  Perhaps it will be several years after the ANSI standard is
>	adopted, but not till then.
>
>The reason we keep pointing out the existence of standard
>functions to those who would rather (or have to) roll their own
>is to encourage people to start using the standard interface...

Note also that there is a public-domain version of memcpy in the strings
library I wrote (which went out in comp.sources.unix quite some time ago,
and is available from their archives).  It's not fast, but it works.
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

henry@utzoo.uucp (Henry Spencer) (09/18/88)

In article <33391@cca.CCA.COM> g-rh@CCA.CCA.COM (Richard Harter) writes:
>This sounds good, but there is a problem to take into account.  If
>you have your own routine with the same name as the "standard"
>routine there is the potential for problems when you port into
>a system that has the "standard" routine in its library...

This just means that inclusion of the routine in question must be optional,
so it can be disabled on such systems.  No big deal.  Possibly the best way
to do this is to #ifdef the user-supplied routine, so that an explicit -D
option (or whatever) is required to use it.
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

bill@proxftl.UUCP (T. William Wells) (09/18/88)

In article <7076@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
: A while back, somebody wrote (explaining why they hadn't and/or
: wouldn't use a newly standardized function):
:
:       I doubt that memcpy even existed then; and it is *not* standard
:       now.  Perhaps it will be several years after the ANSI standard is
:       adopted, but not till then.

That was me talking.  And you have the story wrong.  Duff wrote
an unrolled loop some time in the past to do approximately what
memcpy does, inline, before memcpy was generally available;
moreover, the circumstances were such that even if these routines
had been available, it wouldn't have been good programming for
him to use them.

Please avoid taking things out of context.

---
Bill
novavax!proxftl!bill

g-rh@cca.CCA.COM (Richard Harter) (09/19/88)

In article <1988Sep17.211053.8712@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <33391@cca.CCA.COM> g-rh@CCA.CCA.COM (Richard Harter) writes:
>>This sounds good, but there is a problem to take into account.  If
>>you have your own routine with the same name as the "standard"
>>routine there is the potential for problems when you port into
>>a system that has the "standard" routine in its library...

>This just means that inclusion of the routine in question must be optional,
>so it can be disabled on such systems.  No big deal.  Possibly the best way
>to do this is to #ifdef the user-supplied routine, so that an explicit -D
>option (or whatever) is required to use it.

No big deal for me -- I roll my own and use different names, so I don't
have any problems.  I don't need surprises like finding that my version
of a routine breaks the system because there is a system routine with the
same name (and nominal effect) that has side effects that the system relies
on.  It may be that there are no such routines in any of multitude of systems
that I maintain code on.  Given the eccentricities of some of the
implementations out there I have my doubts.  Given the choice between not
having the problem in the first place, and discovering the hard way during
porting that I have to remove my copy of the routine in question, my
choice is clear -- life is too short to solve unnecessary mysteries.
(I also don't want to spend the time and effort of keeping track of 
which routines are available in which releases of different operating
systems, except when absolutely necessary.) However I grant that my
views are dictated by my particular requirements.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.

henry@utzoo.uucp (Henry Spencer) (09/20/88)

In article <33442@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>... I don't need surprises like finding that my version
>of a routine breaks the system because there is a system routine with the
>same name (and nominal effect) that has side effects that the system relies
>on...

If you read the fine print in the X3J11 drafts, this is explicitly forbidden
unless the name is one of those reserved by the standard.  Yes, this will
require revisions to libraries in many implementations.  X3J11 thought it
well worth the trouble, given the increasingly severe problems with name-
space pollution in C.
-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

g-rh@XAIT.XEROX.COM (Richard Harter) (09/21/88)

In article <1988Sep19.213508.13314@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <33442@cca.CCA.COM> g-rh@XAIT.Xerox.COM (Richard Harter) writes:
>>... I don't need surprises like finding that my version
>>of a routine breaks the system because there is a system routine with the
>>same name (and nominal effect) that has side effects that the system relies
>>on...

>If you read the fine print in the X3J11 drafts, this is explicitly forbidden
>unless the name is one of those reserved by the standard.  Yes, this will
>require revisions to libraries in many implementations.  X3J11 thought it
>well worth the trouble, given the increasingly severe problems with name-
>space pollution in C.

I seem to recall this, yes.  Would you care to hazard a guess as to the date
on which I can rely on this being true in all major implementations?  Today?
1992?  1995?  2001?  2061?  :-)

This question is not entirely facetious.  In practice you have to deal with
operating systems and languages as they are today, and you have to plan for
the future.  Perhaps today I avoid potential library routine name conflicts
because of the aforementioned problems.  Perhaps tomorrow I rely on being able
to pick up a superior implementation from the system.  But today and tomorrow
my software has to run on a suite of architectures.  And so it goes.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.