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.edug-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!billg-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.