* Revert "Many Pages: Remove references to C89"
@ 2023-03-10 1:51 Matt Jolly
2023-03-10 1:51 ` [PATCH] Revert "Many pages: " Matt Jolly
2023-03-10 2:22 ` Revert "Many Pages: " Alejandro Colomar
0 siblings, 2 replies; 24+ messages in thread
From: Matt Jolly @ 2023-03-10 1:51 UTC (permalink / raw)
To: linux-man; +Cc: alx.manpages
Hi All
I hope this email finds you well. I am writing to raise an issue that has been causing inconvenience
for me (and potentially others). The recent removal of C89 information from man pages
(72b349dd8c209d7375d4d4f76e2315943d654ee9) has put me in a difficult situation.
As I continue to work on code that adheres to the C89 style, such as cURL, I am unable to quickly
determine if a particular function can be used or if it was introduced in a later standard like C99.
This slows down my workflow and hampers my productivity.
Therefore, I kindly request that we revert the changes made in the "Many pages: Remove references to C89" patch.
Furthermore, I urge everyone to recognize the importance of this information and ensure it is not removed from man pages in the future.
Thank you for your attention to this matter. Please let me know if you have any questions or concerns.
Cheers,
Matt
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH] Revert "Many pages: Remove references to C89"
2023-03-10 1:51 Revert "Many Pages: Remove references to C89" Matt Jolly
@ 2023-03-10 1:51 ` Matt Jolly
2023-03-10 2:22 ` Revert "Many Pages: " Alejandro Colomar
1 sibling, 0 replies; 24+ messages in thread
From: Matt Jolly @ 2023-03-10 1:51 UTC (permalink / raw)
To: linux-man; +Cc: alx.manpages, Matt Jolly
This reverts commit 72b349dd8c209d7375d4d4f76e2315943d654ee9.
Signed-off-by: Matt Jolly <Matt.Jolly@footclan.ninja>
---
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 13 +++++++++++++
| 2 +-
| 2 +-
| 9 ++++++++-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 6 ++++++
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 14 ++++++++++----
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 6 ++++--
| 2 +-
| 2 +-
| 2 +-
man3/rand.3 | 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 10 +++++++++-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 3 +++
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
| 2 +-
88 files changed, 134 insertions(+), 89 deletions(-)
--git a/man2/rename.2 b/man2/rename.2
index 08e7958f3..5007ef6b6 100644
--- a/man2/rename.2
+++ b/man2/rename.2
@@ -497,7 +497,7 @@ library support was added in glibc 2.4.
was added in Linux 3.15; library support was added in glibc 2.28.
.SH STANDARDS
.BR rename ():
-4.3BSD, C99, POSIX.1-2001, POSIX.1-2008.
+4.3BSD, C89, C99, POSIX.1-2001, POSIX.1-2008.
.PP
.BR renameat ():
POSIX.1-2008.
--git a/man2/signal.2 b/man2/signal.2
index b21abc3b8..d340c734b 100644
--- a/man2/signal.2
+++ b/man2/signal.2
@@ -94,7 +94,7 @@ is set to indicate the error.
.I signum
is invalid.
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH NOTES
The effects of
.BR signal ()
--git a/man2/time.2 b/man2/time.2
index 57558c9aa..2be79cf78 100644
--- a/man2/time.2
+++ b/man2/time.2
@@ -48,7 +48,7 @@ an invalid address may instead trigger a
.B SIGSEGV
signal.
.SH STANDARDS
-SVr4, 4.3BSD, C99, POSIX.1-2001.
+SVr4, 4.3BSD, C89, C99, POSIX.1-2001.
.\" Under 4.3BSD, this call is obsoleted by
.\" .BR gettimeofday (2).
POSIX does not specify any error conditions.
--git a/man3/abort.3 b/man3/abort.3
index ddc0ed536..b0570585d 100644
--- a/man3/abort.3
+++ b/man3/abort.3
@@ -69,7 +69,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-SVr4, POSIX.1-2001, POSIX.1-2008, 4.3BSD, C99.
+SVr4, POSIX.1-2001, POSIX.1-2008, 4.3BSD, C89, C99.
.SH NOTES
Up until glibc 2.26,
if the
--git a/man3/abs.3 b/man3/abs.3
index 06eb12c56..a1293f385 100644
--- a/man3/abs.3
+++ b/man3/abs.3
@@ -77,6 +77,19 @@ T} Thread safety MT-Safe
.sp 1
.SH STANDARDS
POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+.\" POSIX.1 (1996 edition) requires only the
+.\" .BR abs ()
+.\" function.
+C89 only
+includes the
+.BR abs ()
+and
+.BR labs ()
+functions; the functions
+.BR llabs ()
+and
+.BR imaxabs ()
+were added in C99.
.SH NOTES
Trying to take the absolute value of the most negative integer
is not defined.
--git a/man3/acos.3 b/man3/acos.3
index 1628f8125..15466bb20 100644
--- a/man3/acos.3
+++ b/man3/acos.3
@@ -111,7 +111,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR asin (3),
.BR atan (3),
--git a/man3/asin.3 b/man3/asin.3
index 76284ed91..e2cbfe96e 100644
--- a/man3/asin.3
+++ b/man3/asin.3
@@ -107,7 +107,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR acos (3),
.BR atan (3),
--git a/man3/assert.3 b/man3/assert.3
index dfb476399..0e0418e6f 100644
--- a/man3/assert.3
+++ b/man3/assert.3
@@ -74,7 +74,14 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
+In C89,
+.I expression
+is required to be of type
+.I int
+and undefined behavior results if it is not, but in C99
+it may have any scalar type.
+.\" See Defect Report 107 for more details.
.SH BUGS
.BR assert ()
is implemented as a macro; if the expression tested has side-effects,
--git a/man3/atan.3 b/man3/atan.3
index e163db539..f95bc073c 100644
--- a/man3/atan.3
+++ b/man3/atan.3
@@ -92,7 +92,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR acos (3),
.BR asin (3),
--git a/man3/atan2.3 b/man3/atan2.3
index 186209495..e4284d343 100644
--- a/man3/atan2.3
+++ b/man3/atan2.3
@@ -164,7 +164,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR acos (3),
.BR asin (3),
--git a/man3/atexit.3 b/man3/atexit.3
index 3afdcf1b0..363124cc5 100644
--- a/man3/atexit.3
+++ b/man3/atexit.3
@@ -76,7 +76,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
Functions registered using
.BR atexit ()
--git a/man3/atof.3 b/man3/atof.3
index 913060cbd..22d1c50da 100644
--- a/man3/atof.3
+++ b/man3/atof.3
@@ -58,7 +58,7 @@ T} Thread safety MT-Safe locale
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH SEE ALSO
.BR atoi (3),
.BR atol (3),
--git a/man3/atoi.3 b/man3/atoi.3
index ca7c9fe27..10cc66eba 100644
--- a/man3/atoi.3
+++ b/man3/atoi.3
@@ -85,6 +85,12 @@ T} Thread safety MT-Safe locale
.sp 1
.SH STANDARDS
POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+C89 and
+POSIX.1-1996 include the functions
+.BR atoi ()
+and
+.BR atol ()
+only.
.\" .SH NOTES
.\" Linux libc provided
.\" .BR atoq ()
--git a/man3/bsearch.3 b/man3/bsearch.3
index 790b0b7d9..d27a57475 100644
--- a/man3/bsearch.3
+++ b/man3/bsearch.3
@@ -78,7 +78,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH EXAMPLES
The example below first sorts an array of structures using
.BR qsort (3),
--git a/man3/ceil.3 b/man3/ceil.3
index acad6fc58..3957c514d 100644
--- a/man3/ceil.3
+++ b/man3/ceil.3
@@ -79,7 +79,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH NOTES
SUSv2 and POSIX.1-2001 contain text about overflow (which might set
.I errno
--git a/man3/clock.3 b/man3/clock.3
index 488b94e5b..49d92238c 100644
--- a/man3/clock.3
+++ b/man3/clock.3
@@ -49,7 +49,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
XSI requires that
.B CLOCKS_PER_SEC
equals 1000000 independent
--git a/man3/ctime.3 b/man3/ctime.3
index b94e66bd6..31f3e66db 100644
--- a/man3/ctime.3
+++ b/man3/ctime.3
@@ -302,7 +302,7 @@ T}
.sp 1
.SH STANDARDS
POSIX.1-2001.
-C99 specifies
+C89 and C99 specify
.BR asctime (),
.BR ctime (),
.BR gmtime (),
--git a/man3/difftime.3 b/man3/difftime.3
index b85254cd0..051800888 100644
--- a/man3/difftime.3
+++ b/man3/difftime.3
@@ -47,7 +47,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
On a POSIX system,
.I time_t
--git a/man3/div.3 b/man3/div.3
index 375435dd9..29b9493a2 100644
--- a/man3/div.3
+++ b/man3/div.3
@@ -85,7 +85,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
The functions
.BR lldiv ()
and
--git a/man3/exit.3 b/man3/exit.3
index 885335846..d94ac6eb7 100644
--- a/man3/exit.3
+++ b/man3/exit.3
@@ -94,7 +94,7 @@ The
function uses a global variable that is not protected,
so it is not thread-safe.
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
The behavior is undefined if one of the functions registered using
.BR atexit (3)
--git a/man3/exp.3 b/man3/exp.3
index 3bd2874de..d8d49da5e 100644
--- a/man3/exp.3
+++ b/man3/exp.3
@@ -124,7 +124,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR cbrt (3),
.BR cexp (3),
--git a/man3/fabs.3 b/man3/fabs.3
index a3febcfbb..ccb41d0a6 100644
--- a/man3/fabs.3
+++ b/man3/fabs.3
@@ -83,7 +83,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR abs (3),
.BR cabs (3),
--git a/man3/fclose.3 b/man3/fclose.3
index 2c55efa69..213e36bb7 100644
--- a/man3/fclose.3
+++ b/man3/fclose.3
@@ -83,7 +83,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH NOTES
Note that
.BR fclose ()
--git a/man3/ferror.3 b/man3/ferror.3
index cf9ed1645..9d9ebe23a 100644
--- a/man3/ferror.3
+++ b/man3/ferror.3
@@ -93,7 +93,7 @@ The functions
.BR feof (),
and
.BR ferror ()
-conform to C99, POSIX.1-2001, and POSIX.1-2008.
+conform to C89, C99, POSIX.1-2001, and POSIX.1-2008.
.SH NOTES
POSIX.1-2008 specifies
.\"https://www.austingroupbugs.net/view.php?id=401
--git a/man3/fflush.3 b/man3/fflush.3
index 2830824ab..927ff8b2b 100644
--- a/man3/fflush.3
+++ b/man3/fflush.3
@@ -91,7 +91,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-C99, POSIX.1-2001, POSIX.1-2008.
+C89, C99, POSIX.1-2001, POSIX.1-2008.
.PP
POSIX.1-2001 did not specify the behavior for flushing of input streams,
but the behavior is specified in POSIX.1-2008.
--git a/man3/fgetc.3 b/man3/fgetc.3
index 0c124a280..75bb9231b 100644
--- a/man3/fgetc.3
+++ b/man3/fgetc.3
@@ -126,7 +126,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.PP
It is not advisable to mix calls to input functions from the
.I stdio
--git a/man3/floor.3 b/man3/floor.3
index c0fdc3b82..1be5bc094 100644
--- a/man3/floor.3
+++ b/man3/floor.3
@@ -78,7 +78,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH NOTES
SUSv2 and POSIX.1-2001 contain text about overflow (which might set
.I errno
--git a/man3/fmod.3 b/man3/fmod.3
index 2f40ded1e..5c9c2be38 100644
--- a/man3/fmod.3
+++ b/man3/fmod.3
@@ -142,7 +142,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH BUGS
Before glibc 2.10, the glibc implementation did not set
.\" http://sources.redhat.com/bugzilla/show_bug.cgi?id=6784
--git a/man3/fopen.3 b/man3/fopen.3
index 910762b23..2cdaa387c 100644
--- a/man3/fopen.3
+++ b/man3/fopen.3
@@ -291,7 +291,7 @@ T} Thread safety MT-Safe
.SH STANDARDS
.BR fopen (),
.BR freopen ():
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.PP
.BR fdopen ():
POSIX.1-2001, POSIX.1-2008.
--git a/man3/fread.3 b/man3/fread.3
index de609dc24..160ea5f44 100644
--- a/man3/fread.3
+++ b/man3/fread.3
@@ -98,7 +98,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89.
.SH EXAMPLES
The program below demonstrates the use of
.BR fread ()
--git a/man3/frexp.3 b/man3/frexp.3
index 862d8f3e7..8a3692710 100644
--- a/man3/frexp.3
+++ b/man3/frexp.3
@@ -102,7 +102,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH EXAMPLES
The program below produces results such as the following:
.PP
--git a/man3/fseek.3 b/man3/fseek.3
index dc98280e2..7c211a8de 100644
--- a/man3/fseek.3
+++ b/man3/fseek.3
@@ -172,7 +172,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH SEE ALSO
.BR lseek (2),
.BR fseeko (3)
--git a/man3/getenv.3 b/man3/getenv.3
index b9f9ed2c2..51918a955 100644
--- a/man3/getenv.3
+++ b/man3/getenv.3
@@ -98,7 +98,7 @@ T} Thread safety MT-Safe env
.sp 1
.SH STANDARDS
.BR getenv ():
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.PP
.BR secure_getenv ()
is a GNU extension.
--git a/man3/gets.3 b/man3/gets.3
index b77dad5c4..5c3e7b4b2 100644
--- a/man3/gets.3
+++ b/man3/gets.3
@@ -57,7 +57,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-C99, POSIX.1-2001.
+C89, C99, POSIX.1-2001.
.PP
LSB deprecates
.BR gets ().
--git a/man3/isalpha.3 b/man3/isalpha.3
index 668369bcf..baf2cd27b 100644
--- a/man3/isalpha.3
+++ b/man3/isalpha.3
@@ -244,10 +244,9 @@ T} Thread safety MT-Safe
.sp 1
.\" FIXME: need a thread-safety statement about the *_l functions
.SH STANDARDS
-POSIX.1-2001 specifies
+C89 specifies
.BR isalnum (),
.BR isalpha (),
-.BR isblank (),
.BR iscntrl (),
.BR isdigit (),
.BR isgraph (),
@@ -258,9 +257,16 @@ POSIX.1-2001 specifies
.BR isupper (),
and
.BR isxdigit (),
-and also
+but not
+.BR isascii ()
+and
+.BR isblank ().
+POSIX.1-2001
+also specifies those functions, and also
.BR isascii ()
-(as an XSI extension).
+(as an XSI extension)
+and
+.BR isblank ().
C99 specifies all of the preceding functions, except
.BR isascii ().
.PP
--git a/man3/ldexp.3 b/man3/ldexp.3
index fc944b729..e28456c1f 100644
--- a/man3/ldexp.3
+++ b/man3/ldexp.3
@@ -125,7 +125,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR frexp (3),
.BR modf (3),
--git a/man3/localeconv.3 b/man3/localeconv.3
index 5a5ff2430..f900fc119 100644
--- a/man3/localeconv.3
+++ b/man3/localeconv.3
@@ -66,7 +66,7 @@ T}
.ad
.sp 1
.SH STANDARDS
-C99.
+C89, C99.
.SH BUGS
The
.BR printf (3)
--git a/man3/log.3 b/man3/log.3
index 13bac2438..bde58d9f7 100644
--- a/man3/log.3
+++ b/man3/log.3
@@ -124,7 +124,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH BUGS
In glibc 2.5 and earlier,
taking the
--git a/man3/log10.3 b/man3/log10.3
index d64e49c85..00013ca76 100644
--- a/man3/log10.3
+++ b/man3/log10.3
@@ -85,7 +85,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR cbrt (3),
.BR clog10 (3),
--git a/man3/malloc.3 b/man3/malloc.3
index 21f537dd5..6b7d7e4ea 100644
--- a/man3/malloc.3
+++ b/man3/malloc.3
@@ -264,7 +264,7 @@ T} Thread safety MT-Safe
.BR free (),
.BR calloc (),
.BR realloc ():
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.PP
.BR reallocarray ()
is a nonstandard extension that first appeared in OpenBSD 5.6 and FreeBSD 11.0.
--git a/man3/memchr.3 b/man3/memchr.3
index e03001bec..08c93ee82 100644
--- a/man3/memchr.3
+++ b/man3/memchr.3
@@ -121,7 +121,7 @@ T} Thread safety MT-Safe
.sp 1
.SH STANDARDS
.BR memchr ():
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.PP
The
.BR memrchr ()
--git a/man3/memcmp.3 b/man3/memcmp.3
index de712bd0a..e58719848 100644
--- a/man3/memcmp.3
+++ b/man3/memcmp.3
@@ -63,7 +63,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
Do not use
.BR memcmp ()
--git a/man3/memcpy.3 b/man3/memcpy.3
index 5af704e71..77169a27e 100644
--- a/man3/memcpy.3
+++ b/man3/memcpy.3
@@ -53,7 +53,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
Failure to observe the requirement that the memory areas
do not overlap has been the source of significant bugs.
--git a/man3/memmove.3 b/man3/memmove.3
index b8c1c8751..8ee7150e2 100644
--- a/man3/memmove.3
+++ b/man3/memmove.3
@@ -61,7 +61,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH SEE ALSO
.BR bcopy (3),
.BR bstring (3),
--git a/man3/memset.3 b/man3/memset.3
index 07862c431..cce27bb95 100644
--- a/man3/memset.3
+++ b/man3/memset.3
@@ -53,7 +53,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH SEE ALSO
.BR bstring (3),
.BR bzero (3),
--git a/man3/modf.3 b/man3/modf.3
index 42dfbdd88..5662b5a06 100644
--- a/man3/modf.3
+++ b/man3/modf.3
@@ -89,7 +89,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR frexp (3),
.BR ldexp (3)
--git a/man3/offsetof.3 b/man3/offsetof.3
index 423e291ee..7cfba984d 100644
--- a/man3/offsetof.3
+++ b/man3/offsetof.3
@@ -64,7 +64,7 @@ within the given
.IR type ,
in units of bytes.
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH EXAMPLES
On a Linux/i386 system, when compiled using the default
.BR gcc (1)
--git a/man3/perror.3 b/man3/perror.3
index a581c3340..09939d764 100644
--- a/man3/perror.3
+++ b/man3/perror.3
@@ -126,7 +126,7 @@ T} Thread safety MT-Safe race:stderr
.SH STANDARDS
.BR perror (),
.IR errno :
-POSIX.1-2001, POSIX.1-2008, C99, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, 4.3BSD.
.PP
The externals
.I sys_nerr
--git a/man3/pow.3 b/man3/pow.3
index 264adb107..b9a66c929 100644
--- a/man3/pow.3
+++ b/man3/pow.3
@@ -331,7 +331,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH BUGS
.SS Historical bugs (now fixed)
Before glibc 2.28,
--git a/man3/printf.3 b/man3/printf.3
index ac510e59e..322281e51 100644
--- a/man3/printf.3
+++ b/man3/printf.3
@@ -963,10 +963,12 @@ T} Thread safety MT-Safe locale
.BR fprintf (),
.BR printf (),
.BR sprintf (),
-.BR snprintf (),
.BR vprintf (),
.BR vfprintf (),
-.BR vsprintf (),
+.BR vsprintf ():
+POSIX.1-2001, POSIX.1-2008, C89, C99.
+.PP
+.BR snprintf (),
.BR vsnprintf ():
POSIX.1-2001, POSIX.1-2008, C99.
.PP
--git a/man3/puts.3 b/man3/puts.3
index 343bed8ae..10a7f0cb7 100644
--- a/man3/puts.3
+++ b/man3/puts.3
@@ -103,7 +103,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH BUGS
It is not advisable to mix calls to output functions from the
.I stdio
--git a/man3/qsort.3 b/man3/qsort.3
index 55f7b18b6..f4cf5a321 100644
--- a/man3/qsort.3
+++ b/man3/qsort.3
@@ -104,7 +104,7 @@ T} Thread safety MT-Safe
.sp 1
.SH STANDARDS
.BR qsort ():
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
To compare C strings, the comparison function can call
.BR strcmp (3),
--git a/man3/raise.3 b/man3/raise.3
index 4d1a721ae..82903c118 100644
--- a/man3/raise.3
+++ b/man3/raise.3
@@ -63,7 +63,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH NOTES
Since glibc 2.3.3,
.BR raise ()
diff --git a/man3/rand.3 b/man3/rand.3
index f188bdd33..2692bc235 100644
--- a/man3/rand.3
+++ b/man3/rand.3
@@ -138,7 +138,7 @@ The functions
.BR rand ()
and
.BR srand ()
-conform to SVr4, 4.3BSD, C99, POSIX.1-2001.
+conform to SVr4, 4.3BSD, C89, C99, POSIX.1-2001.
The function
.BR rand_r ()
is from POSIX.1-2001.
--git a/man3/remove.3 b/man3/remove.3
index e68c6c5fb..a679b8adb 100644
--- a/man3/remove.3
+++ b/man3/remove.3
@@ -71,7 +71,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, 4.3BSD.
.\" .SH NOTES
.\" Under libc4 and libc5,
.\" .BR remove ()
--git a/man3/setbuf.3 b/man3/setbuf.3
index 4e6bb7362..b4ba7d8f1 100644
--- a/man3/setbuf.3
+++ b/man3/setbuf.3
@@ -164,7 +164,7 @@ The
.BR setbuf ()
and
.BR setvbuf ()
-functions conform to C99.
+functions conform to C89 and C99.
.SH NOTES
POSIX notes
.\" https://www.austingroupbugs.net/view.php?id=397#c799
--git a/man3/setjmp.3 b/man3/setjmp.3
index c66a42503..a8516590a 100644
--- a/man3/setjmp.3
+++ b/man3/setjmp.3
@@ -143,7 +143,7 @@ T} Thread safety MT-Safe
.SH STANDARDS
.BR setjmp (),
.BR longjmp ():
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.PP
.BR sigsetjmp (),
.BR siglongjmp ():
--git a/man3/setlocale.3 b/man3/setlocale.3
index 314dfa0f4..1604ad883 100644
--- a/man3/setlocale.3
+++ b/man3/setlocale.3
@@ -199,7 +199,7 @@ T} Thread safety MT-Unsafe const:locale env
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.PP
The C standards specify only the categories
.BR LC_ALL ,
--git a/man3/sin.3 b/man3/sin.3
index a5f9262a6..ccfddf87a 100644
--- a/man3/sin.3
+++ b/man3/sin.3
@@ -104,7 +104,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH BUGS
Before glibc 2.10, the glibc implementation did not set
.\" http://sources.redhat.com/bugzilla/show_bug.cgi?id=6781
--git a/man3/sinh.3 b/man3/sinh.3
index 9a1821aa9..80eb79a6e 100644
--- a/man3/sinh.3
+++ b/man3/sinh.3
@@ -120,7 +120,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR acosh (3),
.BR asinh (3),
--git a/man3/sqrt.3 b/man3/sqrt.3
index 10c47082c..7fb9a58db 100644
--- a/man3/sqrt.3
+++ b/man3/sqrt.3
@@ -103,7 +103,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR cbrt (3),
.BR csqrt (3),
--git a/man3/stdarg.3 b/man3/stdarg.3
index 468a0904a..3a6601913 100644
--- a/man3/stdarg.3
+++ b/man3/stdarg.3
@@ -224,7 +224,15 @@ T} Thread safety MT-Safe race:ap
.ad
.sp 1
.SH STANDARDS
-C99.
+The
+.BR va_start (),
+.BR va_arg (),
+and
+.BR va_end ()
+macros conform to C89.
+C99 defines the
+.BR va_copy ()
+macro.
.SH BUGS
Unlike the historical
.B varargs
--git a/man3/stdin.3 b/man3/stdin.3
index d1b2375f4..caa65a40f 100644
--- a/man3/stdin.3
+++ b/man3/stdin.3
@@ -119,7 +119,7 @@ The
.IR stdout ,
and
.I stderr
-macros conform to C99
+macros conform to C89
and this standard also stipulates that these three
streams shall be open at program startup.
.SH NOTES
--git a/man3/stdio.3 b/man3/stdio.3
index 2b6c43e01..628f9b690 100644
--- a/man3/stdio.3
+++ b/man3/stdio.3
@@ -335,7 +335,7 @@ T}
.SH STANDARDS
The
.I stdio
-library conforms to C99.
+library conforms to C89.
.SH SEE ALSO
.BR close (2),
.BR open (2),
--git a/man3/stpncpy.3 b/man3/stpncpy.3
index 9d752efe2..70e80195c 100644
--- a/man3/stpncpy.3
+++ b/man3/stpncpy.3
@@ -101,7 +101,7 @@ POSIX.1-2008.
.\" It first appeared in glibc 1.07 in 1993.
.TP
.BR strncpy ()
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH CAVEATS
The name of these functions is confusing.
These functions produce a null-padded character sequence,
--git a/man3/strchr.3 b/man3/strchr.3
index 3eac67008..6cce98001 100644
--- a/man3/strchr.3
+++ b/man3/strchr.3
@@ -107,7 +107,7 @@ T} Thread safety MT-Safe
.SH STANDARDS
.BR strchr (),
.BR strrchr ():
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.PP
.BR strchrnul ()
is a GNU extension.
--git a/man3/strcmp.3 b/man3/strcmp.3
index 8a2ee35f9..63de49e18 100644
--- a/man3/strcmp.3
+++ b/man3/strcmp.3
@@ -95,7 +95,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
POSIX.1 specifies only that:
.RS
--git a/man3/strcoll.3 b/man3/strcoll.3
index e43468bb5..6ebbadcb0 100644
--- a/man3/strcoll.3
+++ b/man3/strcoll.3
@@ -68,7 +68,7 @@ T} Thread safety MT-Safe locale
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH NOTES
In the
.I "POSIX"
--git a/man3/strcpy.3 b/man3/strcpy.3
index 7d04f59f5..02b6fbd8c 100644
--- a/man3/strcpy.3
+++ b/man3/strcpy.3
@@ -123,7 +123,7 @@ POSIX.1-2008.
.BR strcpy ()
.TQ
.BR strcat ()
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH CAVEATS
The strings
.I src
--git a/man3/strerror.3 b/man3/strerror.3
index 96bd8df11..da517f5df 100644
--- a/man3/strerror.3
+++ b/man3/strerror.3
@@ -255,7 +255,7 @@ T} Thread safety MT-Safe
.sp 1
.SH STANDARDS
.BR strerror ()
-is specified by POSIX.1-2001, POSIX.1-2008, and C99.
+is specified by POSIX.1-2001, POSIX.1-2008, C89, and C99.
.BR strerror_r ()
is specified by POSIX.1-2001 and POSIX.1-2008.
.\" FIXME . for later review when Issue 8 is one day released...
--git a/man3/strftime.3 b/man3/strftime.3
index 57b2a38aa..b820abf70 100644
--- a/man3/strftime.3
+++ b/man3/strftime.3
@@ -542,7 +542,7 @@ T} Thread safety MT-Safe env locale
.sp 1
.SH STANDARDS
.BR strftime ():
-SVr4, C99.
+SVr4, C89, C99.
.PD 0
.PP
.PD
--git a/man3/strlen.3 b/man3/strlen.3
index f994a2e90..f8c9bc0c6 100644
--- a/man3/strlen.3
+++ b/man3/strlen.3
@@ -49,7 +49,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, C11, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, C11, SVr4, 4.3BSD.
.SH NOTES
In cases where the input buffer may not contain
a terminating null byte,
--git a/man3/strncat.3 b/man3/strncat.3
index cbf930ec3..af5027c09 100644
--- a/man3/strncat.3
+++ b/man3/strncat.3
@@ -66,7 +66,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH CAVEATS
The name of this function is confusing.
This function has no relation to
--git a/man3/strpbrk.3 b/man3/strpbrk.3
index cb84aeca4..f81a263af 100644
--- a/man3/strpbrk.3
+++ b/man3/strpbrk.3
@@ -55,7 +55,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH SEE ALSO
.BR memchr (3),
.BR strchr (3),
--git a/man3/strsep.3 b/man3/strsep.3
index 794ddbec5..103d9b788 100644
--- a/man3/strsep.3
+++ b/man3/strsep.3
@@ -92,7 +92,7 @@ function was introduced as a replacement for
since the latter cannot handle empty fields.
However,
.BR strtok (3)
-conforms to C99 and hence is more portable.
+conforms to C89/C99 and hence is more portable.
.SH BUGS
Be cautious when using this function.
If you do use it, note that:
--git a/man3/strspn.3 b/man3/strspn.3
index 34d2f1a6a..fbb0b4043 100644
--- a/man3/strspn.3
+++ b/man3/strspn.3
@@ -73,7 +73,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH SEE ALSO
.BR memchr (3),
.BR strchr (3),
--git a/man3/strstr.3 b/man3/strstr.3
index 25bbf9b27..2f41cd162 100644
--- a/man3/strstr.3
+++ b/man3/strstr.3
@@ -74,7 +74,7 @@ T} Thread safety MT-Safe locale
.sp 1
.SH STANDARDS
.BR strstr ():
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.PP
The
.BR strcasestr ()
--git a/man3/strtod.3 b/man3/strtod.3
index 2064b395c..eb1dd650c 100644
--- a/man3/strtod.3
+++ b/man3/strtod.3
@@ -158,6 +158,9 @@ T} Thread safety MT-Safe locale
.sp 1
.SH STANDARDS
POSIX.1-2001, POSIX.1-2008, C99.
+.PP
+.BR strtod ()
+was also described in C89.
.SH NOTES
Since
0 can legitimately be returned
--git a/man3/strtok.3 b/man3/strtok.3
index 9c80c2823..db52fb25c 100644
--- a/man3/strtok.3
+++ b/man3/strtok.3
@@ -174,7 +174,7 @@ T} Thread safety MT-Safe
.SH STANDARDS
.TP
.BR strtok ()
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.TP
.BR strtok_r ()
POSIX.1-2001, POSIX.1-2008.
--git a/man3/strtol.3 b/man3/strtol.3
index da6c98441..34eb63414 100644
--- a/man3/strtol.3
+++ b/man3/strtol.3
@@ -161,7 +161,7 @@ T} Thread safety MT-Safe locale
.sp 1
.SH STANDARDS
.BR strtol ():
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99 SVr4, 4.3BSD.
.PP
.BR strtoll ():
POSIX.1-2001, POSIX.1-2008, C99.
--git a/man3/strtoul.3 b/man3/strtoul.3
index 784094ad6..b43a0b1dd 100644
--- a/man3/strtoul.3
+++ b/man3/strtoul.3
@@ -161,7 +161,7 @@ T} Thread safety MT-Safe locale
.sp 1
.SH STANDARDS
.BR strtoul ():
-POSIX.1-2001, POSIX.1-2008, C99, SVr4.
+POSIX.1-2001, POSIX.1-2008, C89, C99 SVr4.
.PP
.BR strtoull ():
POSIX.1-2001, POSIX.1-2008, C99.
--git a/man3/strxfrm.3 b/man3/strxfrm.3
index 1596273f0..59f96fd94 100644
--- a/man3/strxfrm.3
+++ b/man3/strxfrm.3
@@ -77,7 +77,7 @@ T} Thread safety MT-Safe locale
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD.
.SH SEE ALSO
.BR memcmp (3),
.BR setlocale (3),
--git a/man3/system.3 b/man3/system.3
index 414968fd7..a66ddfa37 100644
--- a/man3/system.3
+++ b/man3/system.3
@@ -119,7 +119,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99.
+POSIX.1-2001, POSIX.1-2008, C89, C99.
.SH NOTES
.BR system ()
provides simplicity and convenience:
--git a/man3/tan.3 b/man3/tan.3
index 83b244c68..ff8de2308 100644
--- a/man3/tan.3
+++ b/man3/tan.3
@@ -129,7 +129,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH BUGS
Before glibc 2.10, the glibc implementation did not set
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=6782
--git a/man3/tanh.3 b/man3/tanh.3
index 36b88f737..6846196bc 100644
--- a/man3/tanh.3
+++ b/man3/tanh.3
@@ -96,7 +96,7 @@ C99, POSIX.1-2001, POSIX.1-2008.
The variant returning
.I double
also conforms to
-SVr4, 4.3BSD.
+SVr4, 4.3BSD, C89.
.SH SEE ALSO
.BR acosh (3),
.BR asinh (3),
--git a/man3/tmpfile.3 b/man3/tmpfile.3
index f238ec7e3..fd39b6e1d 100644
--- a/man3/tmpfile.3
+++ b/man3/tmpfile.3
@@ -78,7 +78,7 @@ T} Thread safety MT-Safe
.ad
.sp 1
.SH STANDARDS
-POSIX.1-2001, POSIX.1-2008, C99, SVr4, 4.3BSD, SUSv2.
+POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD, SUSv2.
.SH NOTES
POSIX.1-2001 specifies:
an error message may be written to
--git a/man3/tmpnam.3 b/man3/tmpnam.3
index 9de98d304..8f9a2af5b 100644
--- a/man3/tmpnam.3
+++ b/man3/tmpnam.3
@@ -107,7 +107,7 @@ T} Thread safety MT-Safe
.sp 1
.SH STANDARDS
.BR tmpnam ():
-SVr4, 4.3BSD, C99, POSIX.1-2001.
+SVr4, 4.3BSD, C89, C99, POSIX.1-2001.
POSIX.1-2008 marks
.BR tmpnam ()
as obsolete.
--git a/man3/toupper.3 b/man3/toupper.3
index c2c98ea30..0df8209d9 100644
--- a/man3/toupper.3
+++ b/man3/toupper.3
@@ -114,7 +114,7 @@ T} Thread safety MT-Safe
.SH STANDARDS
.BR toupper (),
.BR tolower ():
-C99, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
+C89, C99, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
.PP
.BR toupper_l (),
.BR tolower_l ():
--
2.39.2
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 1:51 Revert "Many Pages: Remove references to C89" Matt Jolly
2023-03-10 1:51 ` [PATCH] Revert "Many pages: " Matt Jolly
@ 2023-03-10 2:22 ` Alejandro Colomar
2023-03-10 5:00 ` Oskari Pirhonen
` (2 more replies)
1 sibling, 3 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-10 2:22 UTC (permalink / raw)
To: Matt Jolly, linux-man
[-- Attachment #1.1: Type: text/plain, Size: 2328 bytes --]
Hi Matt,
On 3/10/23 02:51, Matt Jolly wrote:
> Hi All
>
> I hope this email finds you well. I am writing to raise an issue that has been causing inconvenience
> for me (and potentially others). The recent removal of C89 information from man pages
> (72b349dd8c209d7375d4d4f76e2315943d654ee9) has put me in a difficult situation.
> As I continue to work on code that adheres to the C89 style, such as cURL, I am unable to quickly
> determine if a particular function can be used or if it was introduced in a later standard like C99.
> This slows down my workflow and hampers my productivity.
>
> Therefore, I kindly request that we revert the changes made in the "Many pages: Remove references to C89" patch.
> Furthermore, I urge everyone to recognize the importance of this information and ensure it is not removed from man pages in the future.
The main problem was that the existing info about C89 was not consistent.
Some pages declared APIs being standard since C89, while others didn't.
Incorrect info isn't much better than no info.
I'm curious about cURL's real need for C89. I see that cURL uses GNU
extensions (-std=gnu89), which actually pulls most of C99[1] (I think
it pulls the entire C library, and most of the core language).
Virtually all (even MS, which has always been the last in this)
systems support C99; why would you consciously avoid it? Is there
any system that doesn't yet support it? Which are the C libraries
that you need to support that don't provide C99 functions by default
(or at all)?
I'd like to really understand the need for C89 in 2023.
Cheers,
Alex
>
> Thank you for your attention to this matter. Please let me know if you have any questions or concerns.
>
> Cheers,
>
> Matt
>
>
[1]:
$ cat llabs.c
#include <stdlib.h>
int f(void)
{
return llabs(0);
}
$ cc -Wall -Wextra -std=c89 llabs.c -S
llabs.c: In function ‘f’:
llabs.c:5:16: warning: implicit declaration of function ‘llabs’; did you mean ‘labs’? [-Wimplicit-function-declaration]
5 | return llabs(0);
| ^~~~~
| labs
$ cc -Wall -Wextra -std=gnu89 llabs.c -S
$
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 2:22 ` Revert "Many Pages: " Alejandro Colomar
@ 2023-03-10 5:00 ` Oskari Pirhonen
2023-03-10 13:29 ` Alejandro Colomar
2023-03-10 6:40 ` Brian Inglis
2023-03-23 5:32 ` Sam James
2 siblings, 1 reply; 24+ messages in thread
From: Oskari Pirhonen @ 2023-03-10 5:00 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: Matt Jolly, linux-man
[-- Attachment #1: Type: text/plain, Size: 2968 bytes --]
Hi,
On Fri, Mar 10, 2023 at 03:22:12 +0100, Alejandro Colomar wrote:
> Hi Matt,
>
> On 3/10/23 02:51, Matt Jolly wrote:
> > Hi All
> >
> > I hope this email finds you well. I am writing to raise an issue that has been causing inconvenience
> > for me (and potentially others). The recent removal of C89 information from man pages
> > (72b349dd8c209d7375d4d4f76e2315943d654ee9) has put me in a difficult situation.
> > As I continue to work on code that adheres to the C89 style, such as cURL, I am unable to quickly
> > determine if a particular function can be used or if it was introduced in a later standard like C99.
> > This slows down my workflow and hampers my productivity.
> >
> > Therefore, I kindly request that we revert the changes made in the "Many pages: Remove references to C89" patch.
> > Furthermore, I urge everyone to recognize the importance of this information and ensure it is not removed from man pages in the future.
>
> The main problem was that the existing info about C89 was not consistent.
> Some pages declared APIs being standard since C89, while others didn't.
> Incorrect info isn't much better than no info.
>
This is something that can (and should) be fixed then, instead of
blindly dropping all references to C89, no?
> I'm curious about cURL's real need for C89. I see that cURL uses GNU
> extensions (-std=gnu89), which actually pulls most of C99[1] (I think
> it pulls the entire C library, and most of the core language).
>
> Virtually all (even MS, which has always been the last in this)
> systems support C99; why would you consciously avoid it? Is there
> any system that doesn't yet support it? Which are the C libraries
> that you need to support that don't provide C99 functions by default
> (or at all)?
>
> I'd like to really understand the need for C89 in 2023.
>
Some projects might like C89 and there's not much that can be done on
that front without the maintainers having a change of heart...
Personally, I see this more as an issue of manpages inappropriately
editorializing. Mentioning in DESCRIPTION of gets(3) to "Never use this
function" is perfectly fine. In fact, I applaud that it's emphasized
before even getting into what the function does. What is not fine, on
the other hand, is saying that it's in C99 and POSIX.1-2001 but giving
the impression that it's all of a sudden _not_ in C89 anymore.
From the original commit message:
> Let's move forward, so readers get the intended notice that C89 is not a
> useful version of C.
This is incorrect. I can write useful code, even in C89.
More importantly, I find it to be an inappropriate attitude for a manual
to take. The STANDARDS section should not be the place for opinions,
rather facts about when something was standardized. If this is not the
case then perhaps it should be renamed to something else. "STANDARDS
EXCEPT ONES WE DON'T LIKE" comes to mind.
- Oskari
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 2:22 ` Revert "Many Pages: " Alejandro Colomar
2023-03-10 5:00 ` Oskari Pirhonen
@ 2023-03-10 6:40 ` Brian Inglis
2023-03-10 12:49 ` Alejandro Colomar
2023-03-23 5:32 ` Sam James
2 siblings, 1 reply; 24+ messages in thread
From: Brian Inglis @ 2023-03-10 6:40 UTC (permalink / raw)
To: linux-man; +Cc: Matt.Jolly, alx.manpages
On Fri, 10 Mar 2023 03:22:12 +0100, Alejandro Colomar wrote:
> On 3/10/23 02:51, Matt Jolly wrote:
>> I hope this email finds you well. I am writing to raise an issue that has
>> been causing inconvenience for me (and potentially others). The recent
>> removal of C89 information from man pages (72b349dd8c209d7375d4d4f76e2315943d654ee9)
>> has put me in a difficult situation. >> As I continue to work on code that adheres to the C89 style, such as cURL,
>> I am unable to quickly determine if a particular function can be used or if
>> it was introduced in a later standard like C 99. >> This slows down my workflow and hampers my productivity.
>> Therefore, I kindly request that we revert the changes made in the "Many
>> pages: Remove references to C89" patch. >> Furthermore, I urge everyone to recognize the importance of this
>> information and ensure it is not removed from man pages in the future.
> The main problem was that the existing info about C89 was not consistent.
> Some pages declared APIs being standard since C89, while others didn't.
> Incorrect info isn't much better than no info.
> I'm curious about cURL's real need for C89. I see that cURL uses GNU
> extensions (-std=gnu89), which actually pulls most of C99[1] (I think
> it pulls the entire C library, and most of the core language).
> Virtually all (even MS, which has always been the last in this)
> systems support C99; why would you consciously avoid it? Is there
> any system that doesn't yet support it? Which are the C libraries
> that you need to support that don't provide C99 functions by default
> (or at all)?
> I'd like to really understand the need for C89 in 2023.
A quick browse down:
https://curl.se/download.html
shows a number of legacy platforms and versions available:
SCO UnixWare 7.10.3
Linux MIPSel 7.10.7
RISC OS 7.11.0
Linux Slackware S390 7.12.2
BeOS 7.12.3
AmigaOS m68k 7.14.0
SGI IRIX 6.5 7.15.1
Digital Tru64 UNIX 4.0D 7.15.1
SCO Open Server 5 7.15.1
Linux Maemo 3.2 7.15.5
Linux Slackware PPC 7.16.2 Slackintosh
Linux OpenWRT 8.09.1 MIPSel 7.17.1
Linux Unslung 7.17.1
MiNT 7.20.1
QNX 6.5 7.21.7
Linux Ångström PPC 7.24.0
Plan9 7.28.1 9front
Linux Tizen 2.3 ARM 7.28.1
OS/2 7.36.0
which may need e.g. third party patches to remain secure.
Not to mention the legacy systems on those platforms.
Perhaps the US FAA or certain US regional airlines still use these? ;^>
Even DOS DJGPP supports GCC 9.3 with -std=c2x!
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 6:40 ` Brian Inglis
@ 2023-03-10 12:49 ` Alejandro Colomar
0 siblings, 0 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-10 12:49 UTC (permalink / raw)
To: linux-man, Brian Inglis; +Cc: Matt.Jolly
[-- Attachment #1.1: Type: text/plain, Size: 3806 bytes --]
Hi Brian,
On 3/10/23 07:40, Brian Inglis wrote:
> On Fri, 10 Mar 2023 03:22:12 +0100, Alejandro Colomar wrote:
>> On 3/10/23 02:51, Matt Jolly wrote:
>>> I hope this email finds you well. I am writing to raise an issue that has
>>> been causing inconvenience for me (and potentially others). The recent
>>> removal of C89 information from man pages (72b349dd8c209d7375d4d4f76e2315943d654ee9)
>>> has put me in a difficult situation. >> As I continue to work on code that adheres to the C89 style, such as cURL,
>>> I am unable to quickly determine if a particular function can be used or if
>>> it was introduced in a later standard like C 99. >> This slows down my workflow and hampers my productivity.
>>> Therefore, I kindly request that we revert the changes made in the "Many
>>> pages: Remove references to C89" patch. >> Furthermore, I urge everyone to recognize the importance of this
>>> information and ensure it is not removed from man pages in the future.
>> The main problem was that the existing info about C89 was not consistent.
>> Some pages declared APIs being standard since C89, while others didn't.
>> Incorrect info isn't much better than no info.
>> I'm curious about cURL's real need for C89. I see that cURL uses GNU
>> extensions (-std=gnu89), which actually pulls most of C99[1] (I think
>> it pulls the entire C library, and most of the core language).
>> Virtually all (even MS, which has always been the last in this)
>> systems support C99; why would you consciously avoid it? Is there
>> any system that doesn't yet support it? Which are the C libraries
>> that you need to support that don't provide C99 functions by default
>> (or at all)?
>> I'd like to really understand the need for C89 in 2023.
> A quick browse down:
>
> https://curl.se/download.html
>
> shows a number of legacy platforms and versions available:
>
> SCO UnixWare 7.10.3
> Linux MIPSel 7.10.7
> RISC OS 7.11.0
> Linux Slackware S390 7.12.2
> BeOS 7.12.3
> AmigaOS m68k 7.14.0
> SGI IRIX 6.5 7.15.1
> Digital Tru64 UNIX 4.0D 7.15.1
> SCO Open Server 5 7.15.1
> Linux Maemo 3.2 7.15.5
> Linux Slackware PPC 7.16.2 Slackintosh
> Linux OpenWRT 8.09.1 MIPSel 7.17.1
> Linux Unslung 7.17.1
> MiNT 7.20.1
> QNX 6.5 7.21.7
> Linux Ångström PPC 7.24.0
> Plan9 7.28.1 9front
> Linux Tizen 2.3 ARM 7.28.1
> OS/2 7.36.0
It would be interesting to know which compiler and libc is being
used for each of those.
>
> which may need e.g. third party patches to remain secure.
> Not to mention the legacy systems on those platforms.
> Perhaps the US FAA or certain US regional airlines still use these? ;^>
> Even DOS DJGPP supports GCC 9.3 with -std=c2x!
Indeed. Port your compiler (and libc) not your program ;)
C99 has been supported by GCC since basically forever. Most
of it seems to be supported since gcc-3.0 (year 2001),
according to <https://gcc.gnu.org/c99status.html>. Anyway,
in the manual pages, the relevant part is libc. glibc supports
C99 since glibc-2.2 (year 2000), according to
<https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Standard-Libraries.html>.
I would like to see a list of actual systems where there's no
support for C99 functions at all.
Cheers,
Alex
P.S.: Brian, how's that thing about digit separators going on?
I hope I didn't discourage you by being picky in the commit
separation :-) I'm really interested in those patches.
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 5:00 ` Oskari Pirhonen
@ 2023-03-10 13:29 ` Alejandro Colomar
2023-03-10 13:32 ` Alejandro Colomar
2023-03-13 1:42 ` Oskari Pirhonen
0 siblings, 2 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-10 13:29 UTC (permalink / raw)
To: Oskari Pirhonen, Matt Jolly, linux-man; +Cc: Brian Inglis
[-- Attachment #1.1: Type: text/plain, Size: 4646 bytes --]
Hi Oskari,
[reordered your sentences for my reply]
On 3/10/23 06:00, Oskari Pirhonen wrote:
> Hi,
>
> On Fri, Mar 10, 2023 at 03:22:12 +0100, Alejandro Colomar wrote:
[...]
>> The main problem was that the existing info about C89 was not consistent.
>> Some pages declared APIs being standard since C89, while others didn't.
>> Incorrect info isn't much better than no info.
>>
>
> This is something that can (and should) be fixed then, instead of
> blindly dropping all references to C89, no?
We decided back in 2020 that it wasn't worth the extra effort to
check C89.
[...]
>> I'd like to really understand the need for C89 in 2023.
>>
>
> Some projects might like C89 and there's not much that can be done on
> that front without the maintainers having a change of heart...
>
> What is not fine, on
> the other hand, is saying that it's in C99 and POSIX.1-2001 but giving
> the impression that it's all of a sudden _not_ in C89 anymore.
>
> The STANDARDS section should not be the place for opinions,
> rather facts about when something was standardized. If this is not the
> case then perhaps it should be renamed to something else. "STANDARDS
> EXCEPT ONES WE DON'T LIKE" comes to mind.
>
But there are many standard. Who decides which to mention and which
not to mention? How about POSIX.1‐1988, POSIX.1‐1990, and
POSIX.1‐1996?
There are still projects out there that care about POSIX.1‐1996, and
that's not compelling enough for me to do the extra work of searching
if something happens to be supported by it. I will just state
POSIX.1-2001, which is the oldest one I care about, and live with it.
In fact, some pages documented POSIX.1‐1996, and I removed any mentions
to it in the same commit that removed mentions to C89, and even forgot
to mention it in the commit message.
>> I'd like to really understand the need for C89 in 2023.
>>
>
> Some projects might like C89 and there's not much that can be done on
> that front without the maintainers having a change of heart...
If you really want C89, I suggest (as I did in the commit message) that
you read the C89 Standard itself, which will be much more precise than
the Linux man-pages have ever been or will ever be.
However, I suggest you change your heart, and consider C99, since that's
the future (or the past, I should say). I would at least ask that you
show _proof_ that you _need_ C89, before I consider spending some extra
time in documenting C89 in the man pages.
Especially, when you can just download a plain text version of the C89
Standard, and grep(1) for the function name you're interested in:
<https://port70.net/~nsz/c/c89/c89-draft.txt>
I suggest you download that file, and use a function like this:
$ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
$ stdc89 printf
int printf(const char *format, ...);
int printf(const char *format, ...);
>
> Personally, I see this more as an issue of manpages inappropriately
> editorializing. Mentioning in DESCRIPTION of gets(3) to "Never use this
> function" is perfectly fine. In fact, I applaud that it's emphasized
> before even getting into what the function does.
>
> From the original commit message:
>
>> Let's move forward, so readers get the intended notice that C89 is not a
>> useful version of C.
>
> This is incorrect. I can write useful code, even in C89.
>
> More importantly, I find it to be an inappropriate attitude for a manual
> to take.
I admit some editorializing. I think there needs to be some. Otherwise,
there will always be some projects that request support for their
favorite standard. We're close to the point where C89 becomes irrelevant.
I admit we're not yet there, but I'm not sure if it's because it's really
needed, or because some projects blindly stuck to it for fear of the
unknown. I believe it's the latter, and would like to ask you to try C99,
or show some proof that you still need C89 for some reasons that are
different from "I like it". Please understand that I'm not going to
spend my time on documenting POSIX.1-1988 or even K&R C just because
some project likes it (there are still projects that use K&R functions).
However, if you show me that some system can't possibly have C99 in any
form, because there's no C99-compatible compiler or libc that runs on
that system, I would reconsider reverting the patch.
Cheers,
Alex
>
> - Oskari
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 13:29 ` Alejandro Colomar
@ 2023-03-10 13:32 ` Alejandro Colomar
2023-03-13 1:42 ` Oskari Pirhonen
1 sibling, 0 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-10 13:32 UTC (permalink / raw)
To: Oskari Pirhonen, Matt Jolly, linux-man; +Cc: Brian Inglis
[-- Attachment #1.1: Type: text/plain, Size: 4997 bytes --]
On 3/10/23 14:29, Alejandro Colomar wrote:
> Hi Oskari,
>
> [reordered your sentences for my reply]
>
> On 3/10/23 06:00, Oskari Pirhonen wrote:
>> Hi,
>>
>> On Fri, Mar 10, 2023 at 03:22:12 +0100, Alejandro Colomar wrote:
>
> [...]
>
>>> The main problem was that the existing info about C89 was not consistent.
>>> Some pages declared APIs being standard since C89, while others didn't.
>>> Incorrect info isn't much better than no info.
>>>
>>
>> This is something that can (and should) be fixed then, instead of
>> blindly dropping all references to C89, no?
>
> We decided back in 2020 that it wasn't worth the extra effort to
> check C89.
I forgot to add a link here.
<https://lore.kernel.org/linux-man/23bfb4c9-9cab-8d1f-46a2-00932501b5b8@gmail.com/>
>
> [...]
>
>>> I'd like to really understand the need for C89 in 2023.
>>>
>>
>> Some projects might like C89 and there's not much that can be done on
>> that front without the maintainers having a change of heart...
>>
>> What is not fine, on
>> the other hand, is saying that it's in C99 and POSIX.1-2001 but giving
>> the impression that it's all of a sudden _not_ in C89 anymore.
>>
>> The STANDARDS section should not be the place for opinions,
>> rather facts about when something was standardized. If this is not the
>> case then perhaps it should be renamed to something else. "STANDARDS
>> EXCEPT ONES WE DON'T LIKE" comes to mind.
>>
>
> But there are many standard. Who decides which to mention and which
> not to mention? How about POSIX.1‐1988, POSIX.1‐1990, and
> POSIX.1‐1996?
>
> There are still projects out there that care about POSIX.1‐1996, and
> that's not compelling enough for me to do the extra work of searching
> if something happens to be supported by it. I will just state
> POSIX.1-2001, which is the oldest one I care about, and live with it.
>
> In fact, some pages documented POSIX.1‐1996, and I removed any mentions
> to it in the same commit that removed mentions to C89, and even forgot
> to mention it in the commit message.
>
>
>>> I'd like to really understand the need for C89 in 2023.
>>>
>>
>> Some projects might like C89 and there's not much that can be done on
>> that front without the maintainers having a change of heart...
>
> If you really want C89, I suggest (as I did in the commit message) that
> you read the C89 Standard itself, which will be much more precise than
> the Linux man-pages have ever been or will ever be.
>
> However, I suggest you change your heart, and consider C99, since that's
> the future (or the past, I should say). I would at least ask that you
> show _proof_ that you _need_ C89, before I consider spending some extra
> time in documenting C89 in the man pages.
>
> Especially, when you can just download a plain text version of the C89
> Standard, and grep(1) for the function name you're interested in:
>
> <https://port70.net/~nsz/c/c89/c89-draft.txt>
>
> I suggest you download that file, and use a function like this:
>
> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
> $ stdc89 printf
> int printf(const char *format, ...);
> int printf(const char *format, ...);
>
>
>>
>> Personally, I see this more as an issue of manpages inappropriately
>> editorializing. Mentioning in DESCRIPTION of gets(3) to "Never use this
>> function" is perfectly fine. In fact, I applaud that it's emphasized
>> before even getting into what the function does.
>>
>> From the original commit message:
>>
>>> Let's move forward, so readers get the intended notice that C89 is not a
>>> useful version of C.
>>
>> This is incorrect. I can write useful code, even in C89.
>>
>> More importantly, I find it to be an inappropriate attitude for a manual
>> to take.
>
> I admit some editorializing. I think there needs to be some. Otherwise,
> there will always be some projects that request support for their
> favorite standard. We're close to the point where C89 becomes irrelevant.
> I admit we're not yet there, but I'm not sure if it's because it's really
> needed, or because some projects blindly stuck to it for fear of the
> unknown. I believe it's the latter, and would like to ask you to try C99,
> or show some proof that you still need C89 for some reasons that are
> different from "I like it". Please understand that I'm not going to
> spend my time on documenting POSIX.1-1988 or even K&R C just because
> some project likes it (there are still projects that use K&R functions).
>
> However, if you show me that some system can't possibly have C99 in any
> form, because there's no C99-compatible compiler or libc that runs on
> that system, I would reconsider reverting the patch.
>
> Cheers,
>
> Alex
>
>>
>> - Oskari
>
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 13:29 ` Alejandro Colomar
2023-03-10 13:32 ` Alejandro Colomar
@ 2023-03-13 1:42 ` Oskari Pirhonen
2023-03-13 12:00 ` Alejandro Colomar
1 sibling, 1 reply; 24+ messages in thread
From: Oskari Pirhonen @ 2023-03-13 1:42 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: Matt Jolly, linux-man, Brian Inglis
[-- Attachment #1: Type: text/plain, Size: 5737 bytes --]
Hi,
On Fri, Mar 10, 2023 at 14:29:24 +0100, Alejandro Colomar wrote:
... snip ...
> >> The main problem was that the existing info about C89 was not consistent.
> >> Some pages declared APIs being standard since C89, while others didn't.
> >> Incorrect info isn't much better than no info.
> >>
> >
> > This is something that can (and should) be fixed then, instead of
> > blindly dropping all references to C89, no?
>
> We decided back in 2020 that it wasn't worth the extra effort to
> check C89.
... snip ...
> But there are many standard. Who decides which to mention and which
> not to mention? How about POSIX.1‐1988, POSIX.1‐1990, and
> POSIX.1‐1996?
>
> There are still projects out there that care about POSIX.1‐1996, and
> that's not compelling enough for me to do the extra work of searching
> if something happens to be supported by it. I will just state
> POSIX.1-2001, which is the oldest one I care about, and live with it.
>
> In fact, some pages documented POSIX.1‐1996, and I removed any mentions
> to it in the same commit that removed mentions to C89, and even forgot
> to mention it in the commit message.
>
I'm neutral on removing POSIX.1-1996 if it was barely mentioned to begin
with (a search on patch found just 2 instances of "1996") which is not
the case for C89.
>
> >> I'd like to really understand the need for C89 in 2023.
> >>
> >
> > Some projects might like C89 and there's not much that can be done on
> > that front without the maintainers having a change of heart...
>
> If you really want C89, I suggest (as I did in the commit message) that
> you read the C89 Standard itself, which will be much more precise than
> the Linux man-pages have ever been or will ever be.
>
> However, I suggest you change your heart, and consider C99, since that's
> the future (or the past, I should say). I would at least ask that you
> show _proof_ that you _need_ C89, before I consider spending some extra
> time in documenting C89 in the man pages.
>
I think you misunderstood what I meant here. I've got nothing against
using current versions of the language. Perhaps that was not clear
enough in my message.
> Especially, when you can just download a plain text version of the C89
> Standard, and grep(1) for the function name you're interested in:
>
> <https://port70.net/~nsz/c/c89/c89-draft.txt>
>
> I suggest you download that file, and use a function like this:
>
> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
> $ stdc89 printf
> int printf(const char *format, ...);
> int printf(const char *format, ...);
>
I gave this a quick spin and it seems to work decently well. So thanks
for that. It's still not quite as nice as having C89 mentioned in
STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
you mentioned earlier?
>
> >
> > Personally, I see this more as an issue of manpages inappropriately
> > editorializing. Mentioning in DESCRIPTION of gets(3) to "Never use this
> > function" is perfectly fine. In fact, I applaud that it's emphasized
> > before even getting into what the function does.
> >
> > From the original commit message:
> >
> >> Let's move forward, so readers get the intended notice that C89 is not a
> >> useful version of C.
> >
> > This is incorrect. I can write useful code, even in C89.
> >
> > More importantly, I find it to be an inappropriate attitude for a manual
> > to take.
>
> I admit some editorializing. I think there needs to be some. Otherwise,
> there will always be some projects that request support for their
> favorite standard. We're close to the point where C89 becomes irrelevant.
> I admit we're not yet there, but I'm not sure if it's because it's really
> needed, or because some projects blindly stuck to it for fear of the
> unknown. I believe it's the latter, and would like to ask you to try C99,
> or show some proof that you still need C89 for some reasons that are
> different from "I like it". Please understand that I'm not going to
> spend my time on documenting POSIX.1-1988 or even K&R C just because
> some project likes it (there are still projects that use K&R functions).
>
> However, if you show me that some system can't possibly have C99 in any
> form, because there's no C99-compatible compiler or libc that runs on
> that system, I would reconsider reverting the patch.
>
I appreciate the honesty WRT admitting to editorializing. Even if we
disagree on it here.
"Usefulness" seems to be a hard sell for you, but perhaps you would
reconsider it based on the historical relevance of C89? It was, after
all, the first proper standard of the C language. If you don't want to
promote C89 by having it mentioned alongside the others, perhaps you'd
be open to the idea of adding a historical note? Saying that C89 is
obsolete in the note would be acceptable IMO, but not having any mention
of C89 at all makes the manpages feel incomplete. Others have shared
this sentiment when chatting with them online.
There is also somewhat of a precedent of such a line being included in
STANDARDS. For example, the following excerpts from gets(3) and
printf(3), respectively:
> LSB deprecates gets(). POSIX.1-2008 marks gets() obsolescent.
> ISO C11 removes the specification of gets() from the C language,
> and since version 2.16, glibc header files don't expose the
> function declaration if the _ISOC11_SOURCE feature test macro is
> defined.
> The dprintf() and vdprintf() functions were originally GNU
> extensions that were later standardized in POSIX.1-2008.
- Oskari
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-13 1:42 ` Oskari Pirhonen
@ 2023-03-13 12:00 ` Alejandro Colomar
2023-03-14 5:39 ` Oskari Pirhonen
2023-03-15 4:36 ` Guillem Jover
0 siblings, 2 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-13 12:00 UTC (permalink / raw)
To: Oskari Pirhonen; +Cc: linux-man, Brian Inglis, Matt Jolly
[-- Attachment #1.1: Type: text/plain, Size: 4398 bytes --]
Hi Oskari,
On 3/13/23 02:42, Oskari Pirhonen wrote:
[...]
> I'm neutral on removing POSIX.1-1996 if it was barely mentioned to begin
> with (a search on patch found just 2 instances of "1996") which is not
> the case for C89.
>
[...]
>> <https://port70.net/~nsz/c/c89/c89-draft.txt>
>>
>> I suggest you download that file, and use a function like this:
>>
>> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
>> $ stdc89 printf
>> int printf(const char *format, ...);
>> int printf(const char *format, ...);
>>
>
> I gave this a quick spin and it seems to work decently well. So thanks
> for that.
:-)
> It's still not quite as nice as having C89 mentioned in
> STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
> you mentioned earlier?
Yup, you caught me. That's what I thought when writing the email. :p
>
>>
>>>
>>> Personally, I see this more as an issue of manpages inappropriately
>>> editorializing. Mentioning in DESCRIPTION of gets(3) to "Never use this
>>> function" is perfectly fine. In fact, I applaud that it's emphasized
>>> before even getting into what the function does.
>>>
>>> From the original commit message:
>>>
>>>> Let's move forward, so readers get the intended notice that C89 is not a
>>>> useful version of C.
>>>
>>> This is incorrect. I can write useful code, even in C89.
>>>
>>> More importantly, I find it to be an inappropriate attitude for a manual
>>> to take.
>>
>> I admit some editorializing. I think there needs to be some. Otherwise,
>> there will always be some projects that request support for their
>> favorite standard. We're close to the point where C89 becomes irrelevant.
>> I admit we're not yet there, but I'm not sure if it's because it's really
>> needed, or because some projects blindly stuck to it for fear of the
>> unknown. I believe it's the latter, and would like to ask you to try C99,
>> or show some proof that you still need C89 for some reasons that are
>> different from "I like it". Please understand that I'm not going to
>> spend my time on documenting POSIX.1-1988 or even K&R C just because
>> some project likes it (there are still projects that use K&R functions).
>>
>> However, if you show me that some system can't possibly have C99 in any
>> form, because there's no C99-compatible compiler or libc that runs on
>> that system, I would reconsider reverting the patch.
>>
>
> I appreciate the honesty WRT admitting to editorializing. Even if we
> disagree on it here.
>
> "Usefulness" seems to be a hard sell for you, but perhaps you would
> reconsider it based on the historical relevance of C89? It was, after
> all, the first proper standard of the C language. If you don't want to
> promote C89 by having it mentioned alongside the others, perhaps you'd
> be open to the idea of adding a historical note?
I've been considering something like that for a long time. The
STANDARDS section (previously known as CONFORMING TO), is a mix of a
proper standards section, and what a HISTORY section should contain.
It would be interesting to do a split, and inaugurate a HISTORY section.
For that section, I would keep any references to C89, since as you say
it's historically very relevant. Thus, I will revert the patch, and later apply some patches that move the info without discarding it.
Cheers,
Alex
> Saying that C89 is
> obsolete in the note would be acceptable IMO, but not having any mention
> of C89 at all makes the manpages feel incomplete. Others have shared
> this sentiment when chatting with them online.
>
> There is also somewhat of a precedent of such a line being included in
> STANDARDS. For example, the following excerpts from gets(3) and
> printf(3), respectively:
>
>> LSB deprecates gets(). POSIX.1-2008 marks gets() obsolescent.
>> ISO C11 removes the specification of gets() from the C language,
>> and since version 2.16, glibc header files don't expose the
>> function declaration if the _ISOC11_SOURCE feature test macro is
>> defined.
>
>> The dprintf() and vdprintf() functions were originally GNU
>> extensions that were later standardized in POSIX.1-2008.
>
> - Oskari
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-13 12:00 ` Alejandro Colomar
@ 2023-03-14 5:39 ` Oskari Pirhonen
2023-03-15 12:30 ` Alejandro Colomar
2023-03-15 4:36 ` Guillem Jover
1 sibling, 1 reply; 24+ messages in thread
From: Oskari Pirhonen @ 2023-03-14 5:39 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man, Brian Inglis, Matt Jolly
[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]
Hi,
On Mon, Mar 13, 2023 at 13:00:52 +0100, Alejandro Colomar wrote:
... snip ...
> >> <https://port70.net/~nsz/c/c89/c89-draft.txt>
> >>
> >> I suggest you download that file, and use a function like this:
> >>
> >> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
> >> $ stdc89 printf
> >> int printf(const char *format, ...);
> >> int printf(const char *format, ...);
> >>
> >
> > I gave this a quick spin and it seems to work decently well. So thanks
> > for that.
>
> :-)
>
> > It's still not quite as nice as having C89 mentioned in
> > STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
> > you mentioned earlier?
>
> Yup, you caught me. That's what I thought when writing the email. :p
>
I played around with this a bit more, and with a little work it should
be possible to query, eg, all the "str*" functions. As it's written,
it's doable with something like this (but not the most elegant):
$ stdc89 'str[[:alnum:]]*'
double strtod(const char *nptr, char **endptr);
long int strtol(const char *nptr, char **endptr, int base);
char *strcpy(char *s1, const char *s2);
char *strcat(char *s1, const char *s2);
int strcmp(const char *s1, const char *s2);
...
The duplicates and leading whitespace is a trivial change.
Looking at the site you linked to for the c89-draft.txt, there's also
C99, C11, and C2x. With yet some more work, it'd be possible to have
equivalent functions for those standards as well. They could even be
combined to create an "std-diff" tool to give, eg, new "str*" functions
introduced in C89 -> C99.
Perhaps such a tool already exists, but I thought it worth mentioning
here in case anyone reading this gets inspired to write it. I've added
it to my (ever growing) TODO list, but don't know when I might get
around to actually giving it a go.
... snip ...
> > "Usefulness" seems to be a hard sell for you, but perhaps you would
> > reconsider it based on the historical relevance of C89? It was, after
> > all, the first proper standard of the C language. If you don't want to
> > promote C89 by having it mentioned alongside the others, perhaps you'd
> > be open to the idea of adding a historical note?
>
> I've been considering something like that for a long time. The
> STANDARDS section (previously known as CONFORMING TO), is a mix of a
> proper standards section, and what a HISTORY section should contain.
>
> It would be interesting to do a split, and inaugurate a HISTORY section.
> For that section, I would keep any references to C89, since as you say
> it's historically very relevant. Thus, I will revert the patch, and later apply some patches that move the info without discarding it.
>
Well this is good news, and if you ask me, an improvement in the long
run instead of just returning to the status quo.
Much appreciated :)
- Oskari
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-13 12:00 ` Alejandro Colomar
2023-03-14 5:39 ` Oskari Pirhonen
@ 2023-03-15 4:36 ` Guillem Jover
1 sibling, 0 replies; 24+ messages in thread
From: Guillem Jover @ 2023-03-15 4:36 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: Oskari Pirhonen, linux-man, Brian Inglis, Matt Jolly
Hi!
I had in mind starting a similar thread like this some days ago, but
did not find the time, so thanks for doing that!
On Mon, 2023-03-13 at 13:00:52 +0100, Alejandro Colomar wrote:
> On 3/13/23 02:42, Oskari Pirhonen wrote:
> > "Usefulness" seems to be a hard sell for you, but perhaps you would
> > reconsider it based on the historical relevance of C89? It was, after
> > all, the first proper standard of the C language. If you don't want to
> > promote C89 by having it mentioned alongside the others, perhaps you'd
> > be open to the idea of adding a historical note?
> I've been considering something like that for a long time. The
> STANDARDS section (previously known as CONFORMING TO), is a mix of a
> proper standards section, and what a HISTORY section should contain.
>
> It would be interesting to do a split, and inaugurate a HISTORY section.
> For that section, I would keep any references to C89, since as you say
> it's historically very relevant. Thus, I will revert the patch, and later apply some patches that move the info without discarding it.
As long as the information is preserved, because as has been mentioned
in the thread it is helpful when dealing with codebases that restrict
to C89 for whatever reason, this seems good. :) And also to canvas for
how long an interface has been around.
> > Saying that C89 is
> > obsolete in the note would be acceptable IMO, but not having any mention
> > of C89 at all makes the manpages feel incomplete. Others have shared
> > this sentiment when chatting with them online.
For me what seemed rather confusing was that mentions of C89 were
removed but there are references to stuff like «4.xBSD», so I guess
that's why it felt incomplete to me too. (Not suggesting to remove
those either! But I guess this might have planted the idea now. :)
In any case, thanks for the revert!
Regards,
Guillem
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-14 5:39 ` Oskari Pirhonen
@ 2023-03-15 12:30 ` Alejandro Colomar
2023-03-15 12:53 ` Alejandro Colomar
2023-03-15 16:51 ` Brian Inglis
0 siblings, 2 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-15 12:30 UTC (permalink / raw)
To: linux-man, Oskari Pirhonen; +Cc: Brian Inglis, Matt Jolly, Guillem Jover
[-- Attachment #1.1: Type: text/plain, Size: 3871 bytes --]
Hi Oskari,
On 3/14/23 06:39, Oskari Pirhonen wrote:
> Hi,
>
> On Mon, Mar 13, 2023 at 13:00:52 +0100, Alejandro Colomar wrote:
>
> ... snip ...
>
>>>> <https://port70.net/~nsz/c/c89/c89-draft.txt>
>>>>
>>>> I suggest you download that file, and use a function like this:
>>>>
>>>> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
>>>> $ stdc89 printf
>>>> int printf(const char *format, ...);
>>>> int printf(const char *format, ...);
>>>>
>>>
>>> I gave this a quick spin and it seems to work decently well. So thanks
>>> for that.
>>
>> :-)
>>
>>> It's still not quite as nice as having C89 mentioned in
>>> STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
>>> you mentioned earlier?
>>
>> Yup, you caught me. That's what I thought when writing the email. :p
>>
>
> I played around with this a bit more, and with a little work it should
> be possible to query, eg, all the "str*" functions. As it's written,
> it's doable with something like this (but not the most elegant):
>
> $ stdc89 'str[[:alnum:]]*'
> double strtod(const char *nptr, char **endptr);
> long int strtol(const char *nptr, char **endptr, int base);
> char *strcpy(char *s1, const char *s2);
> char *strcat(char *s1, const char *s2);
> int strcmp(const char *s1, const char *s2);
> ...
>
> The duplicates and leading whitespace is a trivial change.
stdc89()
{
grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt \
| sort \
| uniq;
}
That seems to be enough. I don't know if in some cases there will be
whitespace difference that will make this not work, but I tried with
'printf' and 'gets' and it seems to work so far.
>
> Looking at the site you linked to for the c89-draft.txt, there's also
> C99, C11, and C2x. With yet some more work, it'd be possible to have
> equivalent functions for those standards as well. They could even be
> combined to create an "std-diff" tool to give, eg, new "str*" functions
> introduced in C89 -> C99.
>
> Perhaps such a tool already exists, but I thought it worth mentioning
> here in case anyone reading this gets inspired to write it. I've added
> it to my (ever growing) TODO list, but don't know when I might get
> around to actually giving it a go.
Interesting idea. Sounds fun to do. I'll check if we can redistribute
the drafts of the standard in the Linux man-pages repo. If so, we could
have the standard .txt files in some directory inside the repo, and then
have a script that reads those files.
>
> ... snip ...
>
>>> "Usefulness" seems to be a hard sell for you, but perhaps you would
>>> reconsider it based on the historical relevance of C89? It was, after
>>> all, the first proper standard of the C language. If you don't want to
>>> promote C89 by having it mentioned alongside the others, perhaps you'd
>>> be open to the idea of adding a historical note?
>>
>> I've been considering something like that for a long time. The
>> STANDARDS section (previously known as CONFORMING TO), is a mix of a
>> proper standards section, and what a HISTORY section should contain.
>>
>> It would be interesting to do a split, and inaugurate a HISTORY section.
>> For that section, I would keep any references to C89, since as you say
>> it's historically very relevant. Thus, I will revert the patch, and later apply some patches that move the info without discarding it.
>>
>
> Well this is good news, and if you ask me, an improvement in the long
> run instead of just returning to the status quo.
Nice :)
>
> Much appreciated :)
You're welcome :-)
>
> - Oskari
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 12:30 ` Alejandro Colomar
@ 2023-03-15 12:53 ` Alejandro Colomar
2023-03-15 12:54 ` Alejandro Colomar
2023-03-15 14:22 ` Alejandro Colomar
2023-03-15 16:51 ` Brian Inglis
1 sibling, 2 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-15 12:53 UTC (permalink / raw)
To: linux-man, Oskari Pirhonen; +Cc: Brian Inglis, Matt Jolly, Guillem Jover
[-- Attachment #1.1: Type: text/plain, Size: 6775 bytes --]
Hi Oskari,
On 3/15/23 13:30, Alejandro Colomar wrote:
> stdc89()
> {
> grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt \
> | sort \
> | uniq;
> }
I found a bug. I was missing '_' in identifier names. So it didn't
match memcpy(3), which uses size_t. Also, I found some spurious match,
so added a '$' anchor after the ';'.
stdc89()
{
grep "[[:alpha:]] \**\b$1([[:alnum:]*,._ ]*);" /path/to/c89-draft.txt \
| sort \
| uniq;
}
This function finds 136 declarations in C89. I'm not sure if that's
all of them. Is anyone missing any?
Cheers,
Alex
$ stdc89 '[[:alpha:]][[:alnum:]]\+' | wc -l
136
$ stdc89 '[[:alpha:]][[:alnum:]]\+'
FILE *fopen(const char *filename, const char *mode);
FILE *tmpfile(void);
char *asctime(const struct tm *timeptr);
char *ctime(const time_t *timer);
char *fgets(char *s, int n, FILE *stream);
char *getenv(const char *name);
char *gets(char *s);
char *setlocale(int category, const char *locale);
char *strcat(char *s1, const char *s2);
char *strchr(const char *s, int c);
char *strcpy(char *s1, const char *s2);
char *strerror(int errnum);
char *strncat(char *s1, const char *s2, size_t n);
char *strncpy(char *s1, const char *s2, size_t n);
char *strpbrk(const char *s1, const char *s2);
char *strrchr(const char *s, int c);
char *strstr(const char *s1, const char *s2);
char *strtok(char *s1, const char *s2);
char *tmpnam(char *s);
clock_t clock(void);
div_t div(int numer, int denom);
double acos(double x);
double asin(double x);
double atan(double x);
double atan2(double y, double x);
double atof(const char *nptr);
double ceil(double x);
double cos(double x);
double cosh(double x);
double difftime(time_t time1, time_t time0);
double exp(double x);
double fabs(double x);
double floor(double x);
double fmod(double x, double y);
double frexp(double value, int *exp);
double ldexp(double x, int exp);
double log(double x);
double log10(double x);
double modf(double value, double *iptr);
double pow(double x, double y);
double sin(double x);
double sinh(double x);
double sqrt(double x);
double strtod(const char *nptr, char **endptr);
double tan(double x);
double tanh(double x);
extern int atoi(const char *);
extern void *alloc();
int abs(int j);
int atoi(const char *nptr);
int fclose(FILE *stream);
int feof(FILE *stream);
int ferror(FILE *stream);
int fflush(FILE *stream);
int fgetc(FILE *stream);
int fgetpos(FILE *stream, fpos_t *pos);
int fprintf(FILE *stream, const char *format, ...);
int fputc(int c, FILE *stream);
int fputs(const char *s, FILE *stream);
int fscanf(FILE *stream, const char *format, ...);
int fseek(FILE *stream, long int offset, int whence);
int fsetpos(FILE *stream, const fpos_t *pos);
int getc(FILE *stream);
int getchar(void);
int isalnum(int c);
int isalpha(int c);
int iscntrl(int c);
int isdigit(int c);
int isgraph(int c);
int islower(int c);
int isprint(int c);
int ispunct(int c);
int isspace(int c);
int isupper(int c);
int isxdigit(int c);
int mblen(const char *s, size_t n);
int mbtowc(wchar_t *pwc, const char *s, size_t n);
int memcmp(const void *s1, const void *s2, size_t n);
int printf(const char *format, ...);
int putc(int c, FILE *stream);
int putchar(int c);
int puts(const char *s);
int raise(int sig);
int rand(void);
int remove(const char *filename);
int rename(const char *old, const char *new);
int scanf(const char *format, ...);
int setjmp(jmp_buf env);
int setvbuf(FILE *stream, char *buf, int mode, size_t size);
int sprintf(char *s, const char *format, ...);
int sscanf(const char *s, const char *format, ...);
int strcmp(const char *s1, const char *s2);
int strcoll(const char *s1, const char *s2);
int strncmp(const char *s1, const char *s2, size_t n);
int system(const char *string);
int tolower(int c);
int toupper(int c);
int ungetc(int c, FILE *stream);
int vfprintf(FILE *stream, const char *format, va_list arg);
int vprintf(const char *format, va_list arg);
int vsprintf(char *s, const char *format, va_list arg);
int wctomb(char *s, wchar_t wchar);
ldiv_t ldiv(long int numer, long int denom);
long int atol(const char *nptr);
long int ftell(FILE *stream);
long int labs(long int j);
long int strtol(const char *nptr, char **endptr, int base);
size_t mbstowcs(wchar_t *pwcs, const char *s, size_t n);
size_t strcspn(const char *s1, const char *s2);
size_t strlen(const char *s);
size_t strspn(const char *s1, const char *s2);
size_t strxfrm(char *s1, const char *s2, size_t n);
size_t wcstombs(char *s, const wchar_t *pwcs, size_t n);
struct lconv *localeconv(void);
struct tm *gmtime(const time_t *timer);
struct tm *localtime(const time_t *timer);
time_t mktime(struct tm *timeptr);
time_t time(time_t *timer);
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void *memchr(const void *s, int c, size_t n);
void *memcpy(void *s1, const void *s2, size_t n);
void *memmove(void *s1, const void *s2, size_t n);
void *memset(void *s, int c, size_t n);
void *realloc(void *ptr, size_t size);
void abort(void);
void assert(int expression);
void clearerr(FILE *stream);
void exit(int status);
void f1(int, ...);
void free(void *ptr);
void longjmp(jmp_buf env, int val);
void perror(const char *s);
void rewind(FILE *stream);
void setbuf(FILE *stream, char *buf);
void srand(unsigned int seed);
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 12:53 ` Alejandro Colomar
@ 2023-03-15 12:54 ` Alejandro Colomar
2023-03-15 14:22 ` Alejandro Colomar
1 sibling, 0 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-15 12:54 UTC (permalink / raw)
To: linux-man, Oskari Pirhonen; +Cc: Brian Inglis, Matt Jolly, Guillem Jover
[-- Attachment #1.1: Type: text/plain, Size: 7300 bytes --]
On 3/15/23 13:53, Alejandro Colomar wrote:
> Hi Oskari,
>
> On 3/15/23 13:30, Alejandro Colomar wrote:
>> stdc89()
>> {
>> grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt \
>> | sort \
>> | uniq;
>> }
>
> I found a bug. I was missing '_' in identifier names. So it didn't
> match memcpy(3), which uses size_t. Also, I found some spurious match,
> so added a '$' anchor after the ';'.
>
>
> stdc89()
> {
> grep "[[:alpha:]] \**\b$1([[:alnum:]*,._ ]*);" /path/to/c89-draft.txt \
I forgot to update this line. It should have been:
grep "[[:alpha:]] \**\b$1([[:alnum:]*,._ ]*);$" /path/to/c89-draft.txt \
> | sort \
> | uniq;
> }
>
>
> This function finds 136 declarations in C89. I'm not sure if that's
> all of them. Is anyone missing any?
>
> Cheers,
>
> Alex
>
>
> $ stdc89 '[[:alpha:]][[:alnum:]]\+' | wc -l
> 136
> $ stdc89 '[[:alpha:]][[:alnum:]]\+'
> FILE *fopen(const char *filename, const char *mode);
> FILE *tmpfile(void);
> char *asctime(const struct tm *timeptr);
> char *ctime(const time_t *timer);
> char *fgets(char *s, int n, FILE *stream);
> char *getenv(const char *name);
> char *gets(char *s);
> char *setlocale(int category, const char *locale);
> char *strcat(char *s1, const char *s2);
> char *strchr(const char *s, int c);
> char *strcpy(char *s1, const char *s2);
> char *strerror(int errnum);
> char *strncat(char *s1, const char *s2, size_t n);
> char *strncpy(char *s1, const char *s2, size_t n);
> char *strpbrk(const char *s1, const char *s2);
> char *strrchr(const char *s, int c);
> char *strstr(const char *s1, const char *s2);
> char *strtok(char *s1, const char *s2);
> char *tmpnam(char *s);
> clock_t clock(void);
> div_t div(int numer, int denom);
> double acos(double x);
> double asin(double x);
> double atan(double x);
> double atan2(double y, double x);
> double atof(const char *nptr);
> double ceil(double x);
> double cos(double x);
> double cosh(double x);
> double difftime(time_t time1, time_t time0);
> double exp(double x);
> double fabs(double x);
> double floor(double x);
> double fmod(double x, double y);
> double frexp(double value, int *exp);
> double ldexp(double x, int exp);
> double log(double x);
> double log10(double x);
> double modf(double value, double *iptr);
> double pow(double x, double y);
> double sin(double x);
> double sinh(double x);
> double sqrt(double x);
> double strtod(const char *nptr, char **endptr);
> double tan(double x);
> double tanh(double x);
> extern int atoi(const char *);
> extern void *alloc();
> int abs(int j);
> int atoi(const char *nptr);
> int fclose(FILE *stream);
> int feof(FILE *stream);
> int ferror(FILE *stream);
> int fflush(FILE *stream);
> int fgetc(FILE *stream);
> int fgetpos(FILE *stream, fpos_t *pos);
> int fprintf(FILE *stream, const char *format, ...);
> int fputc(int c, FILE *stream);
> int fputs(const char *s, FILE *stream);
> int fscanf(FILE *stream, const char *format, ...);
> int fseek(FILE *stream, long int offset, int whence);
> int fsetpos(FILE *stream, const fpos_t *pos);
> int getc(FILE *stream);
> int getchar(void);
> int isalnum(int c);
> int isalpha(int c);
> int iscntrl(int c);
> int isdigit(int c);
> int isgraph(int c);
> int islower(int c);
> int isprint(int c);
> int ispunct(int c);
> int isspace(int c);
> int isupper(int c);
> int isxdigit(int c);
> int mblen(const char *s, size_t n);
> int mbtowc(wchar_t *pwc, const char *s, size_t n);
> int memcmp(const void *s1, const void *s2, size_t n);
> int printf(const char *format, ...);
> int putc(int c, FILE *stream);
> int putchar(int c);
> int puts(const char *s);
> int raise(int sig);
> int rand(void);
> int remove(const char *filename);
> int rename(const char *old, const char *new);
> int scanf(const char *format, ...);
> int setjmp(jmp_buf env);
> int setvbuf(FILE *stream, char *buf, int mode, size_t size);
> int sprintf(char *s, const char *format, ...);
> int sscanf(const char *s, const char *format, ...);
> int strcmp(const char *s1, const char *s2);
> int strcoll(const char *s1, const char *s2);
> int strncmp(const char *s1, const char *s2, size_t n);
> int system(const char *string);
> int tolower(int c);
> int toupper(int c);
> int ungetc(int c, FILE *stream);
> int vfprintf(FILE *stream, const char *format, va_list arg);
> int vprintf(const char *format, va_list arg);
> int vsprintf(char *s, const char *format, va_list arg);
> int wctomb(char *s, wchar_t wchar);
> ldiv_t ldiv(long int numer, long int denom);
> long int atol(const char *nptr);
> long int ftell(FILE *stream);
> long int labs(long int j);
> long int strtol(const char *nptr, char **endptr, int base);
> size_t mbstowcs(wchar_t *pwcs, const char *s, size_t n);
> size_t strcspn(const char *s1, const char *s2);
> size_t strlen(const char *s);
> size_t strspn(const char *s1, const char *s2);
> size_t strxfrm(char *s1, const char *s2, size_t n);
> size_t wcstombs(char *s, const wchar_t *pwcs, size_t n);
> struct lconv *localeconv(void);
> struct tm *gmtime(const time_t *timer);
> struct tm *localtime(const time_t *timer);
> time_t mktime(struct tm *timeptr);
> time_t time(time_t *timer);
> void *calloc(size_t nmemb, size_t size);
> void *malloc(size_t size);
> void *memchr(const void *s, int c, size_t n);
> void *memcpy(void *s1, const void *s2, size_t n);
> void *memmove(void *s1, const void *s2, size_t n);
> void *memset(void *s, int c, size_t n);
> void *realloc(void *ptr, size_t size);
> void abort(void);
> void assert(int expression);
> void clearerr(FILE *stream);
> void exit(int status);
> void f1(int, ...);
> void free(void *ptr);
> void longjmp(jmp_buf env, int val);
> void perror(const char *s);
> void rewind(FILE *stream);
> void setbuf(FILE *stream, char *buf);
> void srand(unsigned int seed);
>
>
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 12:53 ` Alejandro Colomar
2023-03-15 12:54 ` Alejandro Colomar
@ 2023-03-15 14:22 ` Alejandro Colomar
1 sibling, 0 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-15 14:22 UTC (permalink / raw)
To: linux-man, Oskari Pirhonen; +Cc: Brian Inglis, Matt Jolly, Guillem Jover
[-- Attachment #1.1: Type: text/plain, Size: 1286 bytes --]
On 3/15/23 13:53, Alejandro Colomar wrote:
> Hi Oskari,
>
> On 3/15/23 13:30, Alejandro Colomar wrote:
>> stdc89()
>> {
>> grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt \
>> | sort \
>> | uniq;
>> }
>
> I found a bug. I was missing '_' in identifier names. So it didn't
> match memcpy(3), which uses size_t. Also, I found some spurious match,
> so added a '$' anchor after the ';'.
>
>
> stdc89()
> {
> grep "[[:alpha:]] \**\b$1([[:alnum:]*,._ ]*);" /path/to/c89-draft.txt \
> | sort \
> | uniq;
> }
>
>
> This function finds 136 declarations in C89. I'm not sure if that's
> all of them. Is anyone missing any?
Actually, that was missing a few (multi-line declarations, signal(3),
which is quite weird, and asm()). The following seems to be complete
(per the count of ';'):
$ cat stdc89
#!/bin/sh
sed -n '/A.3 LIBRARY SUMMARY/,$p' <c89-draft.txt \
| pcregrep -M "(?s)\b$1 *\([[:alnum:]*,._\s\(\)-]*\);$";
$ ./stdc89 '[[:alpha:]][[:alnum:]_]+' \
| grep ';' \
| wc -l
146
$ sed -n '/A.3 LIBRARY SUMMARY/,$p' <c89-draft.txt \
| grep ' .*);' \
| wc -l
146
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 12:30 ` Alejandro Colomar
2023-03-15 12:53 ` Alejandro Colomar
@ 2023-03-15 16:51 ` Brian Inglis
2023-03-15 17:01 ` Alejandro Colomar
1 sibling, 1 reply; 24+ messages in thread
From: Brian Inglis @ 2023-03-15 16:51 UTC (permalink / raw)
To: linux-man
On 2023-03-15 06:30, Alejandro Colomar wrote:
> On 3/14/23 06:39, Oskari Pirhonen wrote:
>> On Mon, Mar 13, 2023 at 13:00:52 +0100, Alejandro Colomar wrote:
>>>>> <https://port70.net/~nsz/c/c89/c89-draft.txt>
>>>>> I suggest you download that file, and use a function like this:
>>>>> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
>>>>> $ stdc89 printf
>>>>> int printf(const char *format, ...);
>>>>> int printf(const char *format, ...);
>>>> I gave this a quick spin and it seems to work decently well. So thanks
>>>> for that.
>>>> It's still not quite as nice as having C89 mentioned in
>>>> STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
>>>> you mentioned earlier?
>> Looking at the site you linked to for the c89-draft.txt, there's also
>> C99, C11, and C2x. With yet some more work, it'd be possible to have
>> equivalent functions for those standards as well. They could even be
>> combined to create an "std-diff" tool to give, eg, new "str*" functions
>> introduced in C89 -> C99.
>> Perhaps such a tool already exists, but I thought it worth mentioning
>> here in case anyone reading this gets inspired to write it. I've added
>> it to my (ever growing) TODO list, but don't know when I might get
>> around to actually giving it a go.
> Interesting idea. Sounds fun to do. I'll check if we can redistribute
> the drafts of the standard in the Linux man-pages repo. If so, we could
> have the standard .txt files in some directory inside the repo, and then
> have a script that reads those files.
I have an archive of many drafts including (so far):
1.5M Sep 10 1998 N0843-C1999-CD-1998-08.pdf
3.4M May 6 2005 N1124-C1999+TC2-CD-2005-05.pdf
3.7M Sep 8 2007 N1256-C1999+TC3-CD-2007-09.pdf
1.7M Apr 12 2011 N1570-C201X-CD-2011-04.pdf
2.3M Oct 9 2017 N2176-C2017-CD-2017-10.pdf
6.7M Jan 24 11:37 N3088-C2023-CD1-2023-01.pdf
which can be downloaded as:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n####.pdf
Package poppler contains pdftotext which with -layout produces easily searchable
text files.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 16:51 ` Brian Inglis
@ 2023-03-15 17:01 ` Alejandro Colomar
2023-03-15 18:10 ` Tom Schwindl
0 siblings, 1 reply; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-15 17:01 UTC (permalink / raw)
To: linux-man
Hi Brian,
On 3/15/23 17:51, Brian Inglis wrote:
> On 2023-03-15 06:30, Alejandro Colomar wrote:
>> On 3/14/23 06:39, Oskari Pirhonen wrote:
>>> On Mon, Mar 13, 2023 at 13:00:52 +0100, Alejandro Colomar wrote:
>>>>>> <https://port70.net/~nsz/c/c89/c89-draft.txt>
>>>>>> I suggest you download that file, and use a function like this:
>>>>>> $ stdc89() { grep "[[:alpha:]] \**\b$1([[:alnum:]*,. ]*);" /path/to/c89-draft.txt; }
>>>>>> $ stdc89 printf
>>>>>> int printf(const char *format, ...);
>>>>>> int printf(const char *format, ...);
>
>>>>> I gave this a quick spin and it seems to work decently well. So thanks
>>>>> for that.
>
>>>>> It's still not quite as nice as having C89 mentioned in
>>>>> STANDARDS, and couldn't this be leveraged to fix up the inconsistencies
>>>>> you mentioned earlier?
>
>>> Looking at the site you linked to for the c89-draft.txt, there's also
>>> C99, C11, and C2x. With yet some more work, it'd be possible to have
>>> equivalent functions for those standards as well. They could even be
>>> combined to create an "std-diff" tool to give, eg, new "str*" functions
>>> introduced in C89 -> C99.
>>> Perhaps such a tool already exists, but I thought it worth mentioning
>>> here in case anyone reading this gets inspired to write it. I've added
>>> it to my (ever growing) TODO list, but don't know when I might get
>>> around to actually giving it a go.
>
>> Interesting idea. Sounds fun to do. I'll check if we can redistribute
>> the drafts of the standard in the Linux man-pages repo. If so, we could
>> have the standard .txt files in some directory inside the repo, and then
>> have a script that reads those files.
>
> I have an archive of many drafts including (so far):
>
> 1.5M Sep 10 1998 N0843-C1999-CD-1998-08.pdf
> 3.4M May 6 2005 N1124-C1999+TC2-CD-2005-05.pdf
> 3.7M Sep 8 2007 N1256-C1999+TC3-CD-2007-09.pdf
> 1.7M Apr 12 2011 N1570-C201X-CD-2011-04.pdf
> 2.3M Oct 9 2017 N2176-C2017-CD-2017-10.pdf
> 6.7M Jan 24 11:37 N3088-C2023-CD1-2023-01.pdf
>
> which can be downloaded as:
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n####.pdf
Do you know if we can distribute them? which license applied to them?
I'm worried that some distros are very strict in what can be distributed
in a package (e.g., Fedora, Debian (main)). There were issues with
man-pages-posix in the past.
Should we maybe open a separate project iso-c-drafts that installs
drafts of the ISO C standards and maybe some scripts that will be useful
with them?
>
> Package poppler contains pdftotext which with -layout produces easily searchable
> text files.
Nice.
Thanks,
Alex
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 17:01 ` Alejandro Colomar
@ 2023-03-15 18:10 ` Tom Schwindl
2023-03-16 1:43 ` Alejandro Colomar
0 siblings, 1 reply; 24+ messages in thread
From: Tom Schwindl @ 2023-03-15 18:10 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-man
Hi Alex,
> > I have an archive of many drafts including (so far):
> >
> > 1.5M Sep 10 1998 N0843-C1999-CD-1998-08.pdf
> > 3.4M May 6 2005 N1124-C1999+TC2-CD-2005-05.pdf
> > 3.7M Sep 8 2007 N1256-C1999+TC3-CD-2007-09.pdf
> > 1.7M Apr 12 2011 N1570-C201X-CD-2011-04.pdf
> > 2.3M Oct 9 2017 N2176-C2017-CD-2017-10.pdf
> > 6.7M Jan 24 11:37 N3088-C2023-CD1-2023-01.pdf
> >
> > which can be downloaded as:
> >
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n####.pdf
>
> Do you know if we can distribute them? which license applied to them?
> I'm worried that some distros are very strict in what can be distributed
> in a package (e.g., Fedora, Debian (main)). There were issues with
> man-pages-posix in the past.
>
> Should we maybe open a separate project iso-c-drafts that installs
> drafts of the ISO C standards and maybe some scripts that will be useful
> with them?
>
This is probably a legal gray area and I'd be careful.
ISOs license agreement[0] explicitly states the following:
> The ISO publication(s) you order is/are copyrighted by the International
> Organization for Standardization. You acknowledge and agree to respect ISO’s
> copyright in our publications by purchasing, downloading, copying or
> otherwise using (an) ISO publication(s). Except as provided for under this
> Licence Agreement, you may not lend, lease, reproduce, distribute or
> otherwise commercially exploit ISO publication(s). In the case of joint
> standards (such as ISO/IEC standards), this clause shall apply to the
> respective joint copyright ownership.
As we (or a third party) can only produce a plaintext version by downloading the
original PDF draft and converting it, we agree with the above. Thus, we can't
"reproduce" or "distribute" the standard, at least that's my understanding[1].
I highly doubt that major distibutions would take that risk, nor should we.
[0] <https://www.iso.org/terms-conditions-licence-agreement.html#Customer-Licence>
[1] For the record: I'm not a lawyer, this is not legal advice. It's very well
possible that I've overlooked something.
--
Best Regards,
Tom Schwindl
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-15 18:10 ` Tom Schwindl
@ 2023-03-16 1:43 ` Alejandro Colomar
2023-03-18 4:58 ` Oskari Pirhonen
0 siblings, 1 reply; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-16 1:43 UTC (permalink / raw)
To: Tom Schwindl; +Cc: linux-man
[-- Attachment #1.1: Type: text/plain, Size: 2790 bytes --]
Hi Tom,
On 3/15/23 19:10, Tom Schwindl wrote:
> Hi Alex,
>
>>> I have an archive of many drafts including (so far):
>>>
>>> 1.5M Sep 10 1998 N0843-C1999-CD-1998-08.pdf
>>> 3.4M May 6 2005 N1124-C1999+TC2-CD-2005-05.pdf
>>> 3.7M Sep 8 2007 N1256-C1999+TC3-CD-2007-09.pdf
>>> 1.7M Apr 12 2011 N1570-C201X-CD-2011-04.pdf
>>> 2.3M Oct 9 2017 N2176-C2017-CD-2017-10.pdf
>>> 6.7M Jan 24 11:37 N3088-C2023-CD1-2023-01.pdf
>>>
>>> which can be downloaded as:
>>>
>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n####.pdf
>>
>> Do you know if we can distribute them? which license applied to them?
>> I'm worried that some distros are very strict in what can be distributed
>> in a package (e.g., Fedora, Debian (main)). There were issues with
>> man-pages-posix in the past.
>>
>> Should we maybe open a separate project iso-c-drafts that installs
>> drafts of the ISO C standards and maybe some scripts that will be useful
>> with them?
>>
>
> This is probably a legal gray area and I'd be careful.
Yeah, that's what I think. Until I'm 100% sure that it's legal, I
won't do it.
> ISOs license agreement[0] explicitly states the following:
I had some doubts, because since the drafts have always been published
in many sites, I don't know if that's legal, or simply ISO doesn't
enforce the license over drafts... If someone knows for sure and can
clarify, that would help. In fact, maybe I can write to someone in the
committee...
Thanks,
Alex
>
> > The ISO publication(s) you order is/are copyrighted by the International
> > Organization for Standardization. You acknowledge and agree to respect ISO’s
> > copyright in our publications by purchasing, downloading, copying or
> > otherwise using (an) ISO publication(s). Except as provided for under this
> > Licence Agreement, you may not lend, lease, reproduce, distribute or
> > otherwise commercially exploit ISO publication(s). In the case of joint
> > standards (such as ISO/IEC standards), this clause shall apply to the
> > respective joint copyright ownership.
>
> As we (or a third party) can only produce a plaintext version by downloading the
> original PDF draft and converting it, we agree with the above. Thus, we can't
> "reproduce" or "distribute" the standard, at least that's my understanding[1].
> I highly doubt that major distibutions would take that risk, nor should we.
>
>
> [0] <https://www.iso.org/terms-conditions-licence-agreement.html#Customer-Licence>
> [1] For the record: I'm not a lawyer, this is not legal advice. It's very well
> possible that I've overlooked something.
>
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-16 1:43 ` Alejandro Colomar
@ 2023-03-18 4:58 ` Oskari Pirhonen
2023-03-22 1:20 ` Alejandro Colomar
0 siblings, 1 reply; 24+ messages in thread
From: Oskari Pirhonen @ 2023-03-18 4:58 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: Tom Schwindl, linux-man
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
Hi,
On Thu, Mar 16, 2023 at 02:43:54 +0100, Alejandro Colomar wrote:
> Hi Tom,
>
> On 3/15/23 19:10, Tom Schwindl wrote:
> > Hi Alex,
> >>
> >> Do you know if we can distribute them? which license applied to them?
> >> I'm worried that some distros are very strict in what can be distributed
> >> in a package (e.g., Fedora, Debian (main)). There were issues with
> >> man-pages-posix in the past.
> >>
> >> Should we maybe open a separate project iso-c-drafts that installs
> >> drafts of the ISO C standards and maybe some scripts that will be useful
> >> with them?
> >>
> >
> > This is probably a legal gray area and I'd be careful.
>
> Yeah, that's what I think. Until I'm 100% sure that it's legal, I
> won't do it.
>
> > ISOs license agreement[0] explicitly states the following:
>
> I had some doubts, because since the drafts have always been published
> in many sites, I don't know if that's legal, or simply ISO doesn't
> enforce the license over drafts... If someone knows for sure and can
> clarify, that would help. In fact, maybe I can write to someone in the
> committee...
>
> Thanks,
>
> Alex
>
> >
> > > The ISO publication(s) you order is/are copyrighted by the International
> > > Organization for Standardization. You acknowledge and agree to respect ISO’s
> > > copyright in our publications by purchasing, downloading, copying or
> > > otherwise using (an) ISO publication(s). Except as provided for under this
> > > Licence Agreement, you may not lend, lease, reproduce, distribute or
> > > otherwise commercially exploit ISO publication(s). In the case of joint
> > > standards (such as ISO/IEC standards), this clause shall apply to the
> > > respective joint copyright ownership.
> >
> > As we (or a third party) can only produce a plaintext version by downloading the
> > original PDF draft and converting it, we agree with the above. Thus, we can't
> > "reproduce" or "distribute" the standard, at least that's my understanding[1].
> > I highly doubt that major distibutions would take that risk, nor should we.
> >
> >
> > [0] <https://www.iso.org/terms-conditions-licence-agreement.html#Customer-Licence>
> > [1] For the record: I'm not a lawyer, this is not legal advice. It's very well
> > possible that I've overlooked something.
> >
Gentoo has a concept of "fetch restricted packages" [1] where ebuilds
are available through Portage, but you have to provide the distfiles
yourself. Perhaps something similar in spririt can be used here if the
license terms forbid/are unclear about distributing the standards (or
drafts) themselves?
Here's my idea:
- Create the utils with the assumption that the docs exist at some TBD
path and ship them (the utils, that is).
- Include a check for the docs and instruct the user to install them to
that path manually if they don't exist.
- If it turns out the docs can be distributed, the check can be removed.
Although it might be better to keep it around for the sake of the
pickier distros in hopes that they don't patch out the utils from
their packages.
Obligatory I'm not a lawyer either.
For people unfamiliar with Gentoo terminology, "ebuilds" are basically
scripts used to fetch, build, and install packages and "distfiles" are
what's being fetched (source code, etc).
- Oskari
[1]: https://devmanual.gentoo.org/general-concepts/licenses/index.html#license-implied-restrictions
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-18 4:58 ` Oskari Pirhonen
@ 2023-03-22 1:20 ` Alejandro Colomar
0 siblings, 0 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-22 1:20 UTC (permalink / raw)
To: linux-man, Oskari Pirhonen; +Cc: Sam James, Marcos Fouces, Tom Schwindl
[-- Attachment #1.1: Type: text/plain, Size: 5559 bytes --]
[CC += Sam, Marcos]
Hi Oskari, Sam, Marcos,
On 3/18/23 05:58, Oskari Pirhonen wrote:
> Hi,
>
> On Thu, Mar 16, 2023 at 02:43:54 +0100, Alejandro Colomar wrote:
>> Hi Tom,
>>
>> On 3/15/23 19:10, Tom Schwindl wrote:
>>> Hi Alex,
>>>>
>>>> Do you know if we can distribute them? which license applied to them?
>>>> I'm worried that some distros are very strict in what can be distributed
>>>> in a package (e.g., Fedora, Debian (main)). There were issues with
>>>> man-pages-posix in the past.
>>>>
>>>> Should we maybe open a separate project iso-c-drafts that installs
>>>> drafts of the ISO C standards and maybe some scripts that will be useful
>>>> with them?
>>>>
>>>
>>> This is probably a legal gray area and I'd be careful.
>>
>> Yeah, that's what I think. Until I'm 100% sure that it's legal, I
>> won't do it.
>>
>>> ISOs license agreement[0] explicitly states the following:
>>
>> I had some doubts, because since the drafts have always been published
>> in many sites, I don't know if that's legal, or simply ISO doesn't
>> enforce the license over drafts... If someone knows for sure and can
>> clarify, that would help. In fact, maybe I can write to someone in the
>> committee...
>>
>> Thanks,
>>
>> Alex
>>
>>>
>>> > The ISO publication(s) you order is/are copyrighted by the International
>>> > Organization for Standardization. You acknowledge and agree to respect ISO’s
>>> > copyright in our publications by purchasing, downloading, copying or
>>> > otherwise using (an) ISO publication(s). Except as provided for under this
>>> > Licence Agreement, you may not lend, lease, reproduce, distribute or
>>> > otherwise commercially exploit ISO publication(s). In the case of joint
>>> > standards (such as ISO/IEC standards), this clause shall apply to the
>>> > respective joint copyright ownership.
>>>
>>> As we (or a third party) can only produce a plaintext version by downloading the
>>> original PDF draft and converting it, we agree with the above. Thus, we can't
>>> "reproduce" or "distribute" the standard, at least that's my understanding[1].
>>> I highly doubt that major distibutions would take that risk, nor should we.
>>>
>>>
>>> [0] <https://www.iso.org/terms-conditions-licence-agreement.html#Customer-Licence>
>>> [1] For the record: I'm not a lawyer, this is not legal advice. It's very well
>>> possible that I've overlooked something.
>>>
>
> Gentoo has a concept of "fetch restricted packages" [1] where ebuilds
> are available through Portage, but you have to provide the distfiles
> yourself. Perhaps something similar in spririt can be used here if the
> license terms forbid/are unclear about distributing the standards (or
> drafts) themselves?
>
> Here's my idea:
>
> - Create the utils with the assumption that the docs exist at some TBD
> path and ship them (the utils, that is).
I think that would qualify as a "contrib" package in Debian policy. So
that would be for a new package, separate from the man-pages, which
should go in main.
> - Include a check for the docs and instruct the user to install them to
> that path manually if they don't exist.
I'm not even sure about the legality of that. So far I've written the
script assuming the files exist, and we'll see how to get the files
there (I have them in my system). I'll be cautious before writing any
advice on how to get them in a program :).
> - If it turns out the docs can be distributed, the check can be removed.
> Although it might be better to keep it around for the sake of the
> pickier distros in hopes that they don't patch out the utils from
> their packages.
>
> Obligatory I'm not a lawyer either.
>
> For people unfamiliar with Gentoo terminology, "ebuilds" are basically
> scripts used to fetch, build, and install packages and "distfiles" are
> what's being fetched (source code, etc).
>
> - Oskari
>
> [1]: https://devmanual.gentoo.org/general-concepts/licenses/index.html#license-implied-restrictions
Here goes something that works for c89, c99, and c11 (thoroughly tested
only for c89; lightly tested for the others).
I'll create a public git repository for it in my website later this week
(if I find the time this week).
Cheers,
Alex
---
(I might change the interface in the future, and will document it when
I'm convinced by it.)
$ cat /usr/local/bin/stdc
#!/bin/bash
set -Eefuo pipefail;
prefix="/usr/local";
datarootdir="$prefix/share";
docdir="$datarootdir/doc";
err()
{
>&2 echo "$(basename "$0"): error: $*";
exit 1;
}
grep_proto()
{
pcregrep -M "(?s)\b$1 *\([[:alnum:]*,._\s\(\)-]*\);$";
}
c89_libc_summ()
{
sed -n '/A.3 LIBRARY SUMMARY/,$p' <"$docdir/c/c89/c89-draft.txt";
}
c99_libc_summ()
{
sed -n '/Library summary$/,/Sequence points$/p' \
<"$docdir/c/c99/n1256.txt";
}
c11_libc_summ()
{
sed -n '/Library summary$/,/Sequence points$/p' \
<"$docdir/c/c11/n1570.txt";
}
case $# in
0)
err "missing ISO C version.";
;;
1)
err "missing function name.";
;;
2)
;;
*)
shift;
shift;
err "unsupported extra argument(s): $*";
;;
esac;
case "$1" in
c89)
shift;
c89_libc_summ | grep_proto $@;
;;
c99)
shift;
c99_libc_summ | grep_proto $@;
;;
c11)
shift;
c11_libc_summ | grep_proto $@;
;;
*)
err "$1: unsupported ISO C version.";
;;
esac;
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-10 2:22 ` Revert "Many Pages: " Alejandro Colomar
2023-03-10 5:00 ` Oskari Pirhonen
2023-03-10 6:40 ` Brian Inglis
@ 2023-03-23 5:32 ` Sam James
2023-03-23 13:13 ` Alejandro Colomar
2 siblings, 1 reply; 24+ messages in thread
From: Sam James @ 2023-03-23 5:32 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: Matt Jolly, linux-man
[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]
Alejandro Colomar <alx.manpages@gmail.com> writes:
> [[PGP Signed Part:Undecided]]
> Hi Matt,
>
> On 3/10/23 02:51, Matt Jolly wrote:
>> Hi All
>>
>> I hope this email finds you well. I am writing to raise an issue that has been causing inconvenience
>> for me (and potentially others). The recent removal of C89 information from man pages
>> (72b349dd8c209d7375d4d4f76e2315943d654ee9) has put me in a difficult situation.
>> As I continue to work on code that adheres to the C89 style, such as cURL, I am unable to quickly
>> determine if a particular function can be used or if it was introduced in a later standard like C99.
>> This slows down my workflow and hampers my productivity.
>>
>> Therefore, I kindly request that we revert the changes made in the "Many pages: Remove references to C89" patch.
>> Furthermore, I urge everyone to recognize the importance of this information and ensure it is not removed from man pages in the future.
>
> The main problem was that the existing info about C89 was not consistent.
> Some pages declared APIs being standard since C89, while others didn't.
> Incorrect info isn't much better than no info.
>
> I'm curious about cURL's real need for C89. I see that cURL uses GNU
> extensions (-std=gnu89), which actually pulls most of C99[1] (I think
> it pulls the entire C library, and most of the core language).
I don't really agree with it, but the gist is at
https://daniel.haxx.se/blog/2022/11/17/considering-c99-for-curl/.
The general principle here being two things, I guess:
1. It's pretty useful to have this information (even if it's just
on a best-effort basis) because I can cite it in arguments even if
a project is using >= C99.
2. People expect the information to be there, so omitting it ends up
giving the impression something just isn't in C89, rather than the
reader realising the information is removed from the man pages entirely.
but also, and this was the case for Matt here:
3. I don't always have a choice. Especially doing distribution work,
I end up patching and contributing to all sorts of projects, and while
I wish many things would use newer C, they're either dead projects, or
their maintainers are of a strong mind on the matter.
>
> Virtually all (even MS, which has always been the last in this)
> systems support C99; why would you consciously avoid it? Is there
> any system that doesn't yet support it? Which are the C libraries
> that you need to support that don't provide C99 functions by default
> (or at all)?
>
> I'd like to really understand the need for C89 in 2023.
i.e. what I'm saying is that it's not so much about the need, but rather
that changing the man pages just ends up inconveniencing people who
aren't really happy about using C89 either.
best,
sam
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Revert "Many Pages: Remove references to C89"
2023-03-23 5:32 ` Sam James
@ 2023-03-23 13:13 ` Alejandro Colomar
0 siblings, 0 replies; 24+ messages in thread
From: Alejandro Colomar @ 2023-03-23 13:13 UTC (permalink / raw)
To: Sam James; +Cc: Matt Jolly, linux-man
[-- Attachment #1.1: Type: text/plain, Size: 3578 bytes --]
Hi Sam
On 3/23/23 06:32, Sam James wrote:
>
> Alejandro Colomar <alx.manpages@gmail.com> writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hi Matt,
>>
>> On 3/10/23 02:51, Matt Jolly wrote:
>>> Hi All
>>>
>>> I hope this email finds you well. I am writing to raise an issue that has been causing inconvenience
>>> for me (and potentially others). The recent removal of C89 information from man pages
>>> (72b349dd8c209d7375d4d4f76e2315943d654ee9) has put me in a difficult situation.
>>> As I continue to work on code that adheres to the C89 style, such as cURL, I am unable to quickly
>>> determine if a particular function can be used or if it was introduced in a later standard like C99.
>>> This slows down my workflow and hampers my productivity.
>>>
>>> Therefore, I kindly request that we revert the changes made in the "Many pages: Remove references to C89" patch.
>>> Furthermore, I urge everyone to recognize the importance of this information and ensure it is not removed from man pages in the future.
>>
>> The main problem was that the existing info about C89 was not consistent.
>> Some pages declared APIs being standard since C89, while others didn't.
>> Incorrect info isn't much better than no info.
>>
>> I'm curious about cURL's real need for C89. I see that cURL uses GNU
>> extensions (-std=gnu89), which actually pulls most of C99[1] (I think
>> it pulls the entire C library, and most of the core language).
>
> I don't really agree with it, but the gist is at
> https://daniel.haxx.se/blog/2022/11/17/considering-c99-for-curl/.
>
> The general principle here being two things, I guess:
> 1. It's pretty useful to have this information (even if it's just
> on a best-effort basis) because I can cite it in arguments even if
> a project is using >= C99.
>
> 2. People expect the information to be there, so omitting it ends up
> giving the impression something just isn't in C89, rather than the
> reader realising the information is removed from the man pages entirely.
>
> but also, and this was the case for Matt here:
>
> 3. I don't always have a choice. Especially doing distribution work,
> I end up patching and contributing to all sorts of projects, and while
> I wish many things would use newer C, they're either dead projects, or
> their maintainers are of a strong mind on the matter.
>
>>
>> Virtually all (even MS, which has always been the last in this)
>> systems support C99; why would you consciously avoid it? Is there
>> any system that doesn't yet support it? Which are the C libraries
>> that you need to support that don't provide C99 functions by default
>> (or at all)?
>>
>> I'd like to really understand the need for C89 in 2023.
>
> i.e. what I'm saying is that it's not so much about the need, but rather
> that changing the man pages just ends up inconveniencing people who
> aren't really happy about using C89 either.
Makes sense. And yeah, history is always useful, even for corner
cases, which is why we still document things like 4.0BSD. I'm almost
finished in adding the HISTORY section and reorganizing VERSIONS and
STANDARDS (and NOTES). This week or next week, I'll push the commit.
So far, I've done:
536 files changed, 4704 insertions(+), 4278 deletions(-)
And there are still 353 pages pending. :)
But the change is looking quite good. I think it will be a nice
improvement.
Cheers,
Alex
>
> best,
> sam
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2023-03-23 13:13 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-10 1:51 Revert "Many Pages: Remove references to C89" Matt Jolly
2023-03-10 1:51 ` [PATCH] Revert "Many pages: " Matt Jolly
2023-03-10 2:22 ` Revert "Many Pages: " Alejandro Colomar
2023-03-10 5:00 ` Oskari Pirhonen
2023-03-10 13:29 ` Alejandro Colomar
2023-03-10 13:32 ` Alejandro Colomar
2023-03-13 1:42 ` Oskari Pirhonen
2023-03-13 12:00 ` Alejandro Colomar
2023-03-14 5:39 ` Oskari Pirhonen
2023-03-15 12:30 ` Alejandro Colomar
2023-03-15 12:53 ` Alejandro Colomar
2023-03-15 12:54 ` Alejandro Colomar
2023-03-15 14:22 ` Alejandro Colomar
2023-03-15 16:51 ` Brian Inglis
2023-03-15 17:01 ` Alejandro Colomar
2023-03-15 18:10 ` Tom Schwindl
2023-03-16 1:43 ` Alejandro Colomar
2023-03-18 4:58 ` Oskari Pirhonen
2023-03-22 1:20 ` Alejandro Colomar
2023-03-15 4:36 ` Guillem Jover
2023-03-10 6:40 ` Brian Inglis
2023-03-10 12:49 ` Alejandro Colomar
2023-03-23 5:32 ` Sam James
2023-03-23 13:13 ` Alejandro Colomar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.