diff mbox

stpcpy comes from Turbo C [BZ #3629]

Message ID 57337CD7.6090900@redhat.com
State New
Headers show

Commit Message

Florian Weimer May 11, 2016, 6:41 p.m. UTC 
On 05/10/2016 06:37 PM, Ulrich Drepper wrote:
> On Tue, May 10, 2016 at 3:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> +This function is a Turbo C extension.  It is not part of the ISO or
>> +POSIX standards.
>
> Even the current man pages tell you that this isn't right.  Of course
> it was an extension but not introduced in Turbo C.  It was introduced
> earlier.  Amiga Lattice C had it:
>
> http://www.bombjack.org/commodore/amiga/applications/Lattice_C_Compiler_V3_Programmers_Reference_Guide_%28Sep_12_1986%29.pdf

I find it difficult to believe that Turbo C copied from there, I find it 
far more likely that there was a common ancestor.

What about this patch, then?

Thanks,
Florian

Comments

Roland McGrath May 20, 2016, 10:13 p.m. UTC | #1 
I certainly don't think we need to give exact history on the provenance of
each interface.  A simple statement about current standards is good.  But
that could give the erroneous impression that stpcpy was not available in
the GNU C Library before it supported POSIX.1-2008.  (In fact, AFAICT
stpcpy has been in libc since before its first release.)

How about this?

	This function is part of POSIX.1-2008 and later editions, but was
	available in @theglibc{} and other systems as an extension long
	before it was standardized.

I didn't say "GNU extension" to avoid the implication that we were its
inventors.


Thanks,
Roland
Florian Weimer May 23, 2016, 7:37 a.m. UTC | #2 
On 05/21/2016 12:13 AM, Roland McGrath wrote:
> I certainly don't think we need to give exact history on the provenance of
> each interface.  A simple statement about current standards is good.  But
> that could give the erroneous impression that stpcpy was not available in
> the GNU C Library before it supported POSIX.1-2008.  (In fact, AFAICT
> stpcpy has been in libc since before its first release.)
>
> How about this?
>
> 	This function is part of POSIX.1-2008 and later editions, but was
> 	available in @theglibc{} and other systems as an extension long
> 	before it was standardized.
>
> I didn't say "GNU extension" to avoid the implication that we were its
> inventors.

Looks good to me.  Do you want me to commit it in your name, or do you 
want to commit this yourself?

Thanks,
Florian
Roland McGrath May 27, 2016, 7:45 p.m. UTC | #3 
> On 05/21/2016 12:13 AM, Roland McGrath wrote:
> > I certainly don't think we need to give exact history on the provenance of
> > each interface.  A simple statement about current standards is good.  But
> > that could give the erroneous impression that stpcpy was not available in
> > the GNU C Library before it supported POSIX.1-2008.  (In fact, AFAICT
> > stpcpy has been in libc since before its first release.)
> >
> > How about this?
> >
> > 	This function is part of POSIX.1-2008 and later editions, but was
> > 	available in @theglibc{} and other systems as an extension long
> > 	before it was standardized.
> >
> > I didn't say "GNU extension" to avoid the implication that we were its
> > inventors.
> 
> Looks good to me.  Do you want me to commit it in your name, or do you 
> want to commit this yourself?

Please do commit something like this.
diff mbox

Patch

2016-05-10  Florian Weimer  <fweimer@redhat.com>

	[BZ #3629]
	* manual/string.texi (Copying Strings and Arrays): Document
	provenience of the stpcpy function.

diff --git a/manual/string.texi b/manual/string.texi
index 016fd0b..d78381e 100644
--- a/manual/string.texi
+++ b/manual/string.texi
@@ -612,9 +612,7 @@  and @samp{bar} to produce @samp{foobar}, which it then prints.
 @include stpcpy.c.texi
 @end smallexample
 
-This function is not part of the ISO or POSIX standards, and is not
-customary on Unix systems, but we did not invent it either.  Perhaps it
-comes from MS-DOG.
+This function is part of POSIX.1-2008 and later editions.
 
 Its behavior is undefined if the strings overlap.  The function is
 declared in @file{string.h}.