CVS commit: src/lib/libc/stdio
Module Name:src Committed By: christos Date: Fri Mar 29 22:39:41 UTC 2024 Modified Files: src/lib/libc/stdio: fvwrite.c Log Message: >From enh at google dot com in tech-userlevel. Don't limit writes to BUFSIZ, change the limit to INT_MAX; improves performance dramatically. From: https://github.com/apple-oss-distributions/Libc/commit/\ c5a3293354e22262702a3add5b2dfc9bb0b93b85\ #diff-3b844a19cfb0aab1a23f7fbc457d3bce7453513730c489a72f66ff89d6557ff3 To generate a diff of this commit: cvs rdiff -u -r1.30 -r1.31 src/lib/libc/stdio/fvwrite.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src
Committed By: christos
Date: Fri Mar 29 22:39:41 UTC 2024
Modified Files:
src/lib/libc/stdio: fvwrite.c
Log Message:
>From enh at google dot com in tech-userlevel. Don't limit writes to BUFSIZ,
change the limit to INT_MAX; improves performance dramatically. From:
https://github.com/apple-oss-distributions/Libc/commit/\
c5a3293354e22262702a3add5b2dfc9bb0b93b85\
#diff-3b844a19cfb0aab1a23f7fbc457d3bce7453513730c489a72f66ff89d6557ff3
To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/lib/libc/stdio/fvwrite.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/lib/libc/stdio/fvwrite.c
diff -u src/lib/libc/stdio/fvwrite.c:1.30 src/lib/libc/stdio/fvwrite.c:1.31
--- src/lib/libc/stdio/fvwrite.c:1.30 Thu Jul 22 13:08:15 2021
+++ src/lib/libc/stdio/fvwrite.c Fri Mar 29 18:39:41 2024
@@ -1,4 +1,4 @@
-/* $NetBSD: fvwrite.c,v 1.30 2021/07/22 17:08:15 christos Exp $ */
+/* $NetBSD: fvwrite.c,v 1.31 2024/03/29 22:39:41 christos Exp $ */
/*-
* Copyright (c) 1990, 1993
@@ -37,7 +37,7 @@
#if 0
static char sccsid[] = "@(#)fvwrite.c 8.1 (Berkeley) 6/4/93";
#else
-__RCSID("$NetBSD: fvwrite.c,v 1.30 2021/07/22 17:08:15 christos Exp $");
+__RCSID("$NetBSD: fvwrite.c,v 1.31 2024/03/29 22:39:41 christos Exp $");
#endif
#endif /* LIBC_SCCS and not lint */
@@ -99,11 +99,12 @@ __sfvwrite(FILE *fp, struct __suio *uio)
}
if (fp->_flags & __SNBF) {
/*
- * Unbuffered: write up to BUFSIZ bytes at a time.
+ * Unbuffered: write up to INT_MAX bytes at a time, to not
+ * truncate the value of len if it is greater than 2^31 bytes.
*/
do {
GETIOV(;);
- w = (*fp->_write)(fp->_cookie, p, MIN(len, BUFSIZ));
+ w = (*fp->_write)(fp->_cookie, p, MIN(len, INT_MAX));
if (w <= 0)
goto err;
p += w;
@@ -113,7 +114,8 @@ __sfvwrite(FILE *fp, struct __suio *uio)
/*
* Fully buffered: fill partially full buffer, if any,
* and then flush. If there is no partial buffer, write
- * one _bf._size byte chunk directly (without copying).
+ * entire payload directly (without copying) up to a multiple
+ * of the buffer size.
*
* String output is a special case: write as many bytes
* as fit, but pretend we wrote everything. This makes
@@ -159,7 +161,15 @@ __sfvwrite(FILE *fp, struct __suio *uio)
if (fflush(fp))
goto err;
} else if (len >= (size_t)(w = fp->_bf._size)) {
-/* write directly */
+/*
+ * write directly up to INT_MAX or greatest
+ * multiple of buffer size (whatever is
+ * smaller), keeping in the memory buffer the
+ * remaining part of payload that is smaller
+ * than buffer size.
+ */
+if (w != 0)
+ w = MIN(w * (len / w), INT_MAX);
w = (*fp->_write)(fp->_cookie, p, (size_t)w);
if (w <= 0)
goto err;
CVS commit: src/lib/libc/stdio
Module Name:src
Committed By: christos
Date: Sun Apr 3 14:17:53 UTC 2022
Modified Files:
src/lib/libc/stdio: printf.3
Log Message:
Improve wording to avoid confusion about the return value of {v,}asprintf(3)
To generate a diff of this commit:
cvs rdiff -u -r1.70 -r1.71 src/lib/libc/stdio/printf.3
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/lib/libc/stdio/printf.3
diff -u src/lib/libc/stdio/printf.3:1.70 src/lib/libc/stdio/printf.3:1.71
--- src/lib/libc/stdio/printf.3:1.70 Thu Sep 23 08:17:57 2021
+++ src/lib/libc/stdio/printf.3 Sun Apr 3 10:17:53 2022
@@ -1,4 +1,4 @@
-.\" $NetBSD: printf.3,v 1.70 2021/09/23 12:17:57 wiz Exp $
+.\" $NetBSD: printf.3,v 1.71 2022/04/03 14:17:53 christos Exp $
.\"
.\" Copyright (c) 1990, 1991, 1993
.\" The Regents of the University of California. All rights reserved.
@@ -33,7 +33,7 @@
.\"
.\" @(#)printf.3 8.1 (Berkeley) 6/4/93
.\"
-.Dd November 19, 2015
+.Dd April 3, 2022
.Dt PRINTF 3
.Os
.Sh NAME
@@ -141,11 +141,11 @@ floating point formats, positional argum
.Fn asprintf
and
.Fn vasprintf
-return a pointer to a buffer sufficiently large to hold the
-string in the
-.Fa ret
-argument.
-This pointer should be passed to
+set the
+.Fa ret
+argument to a pointer containing the formatted string.
+This pointer
+points to a newly allocated buffer and should be passed to
.Xr free 3
to release the allocated storage when it is no longer needed.
If sufficient space cannot be allocated, these functions
CVS commit: src/lib/libc/stdio
Module Name:src
Committed By: christos
Date: Sun Apr 3 14:17:53 UTC 2022
Modified Files:
src/lib/libc/stdio: printf.3
Log Message:
Improve wording to avoid confusion about the return value of {v,}asprintf(3)
To generate a diff of this commit:
cvs rdiff -u -r1.70 -r1.71 src/lib/libc/stdio/printf.3
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src
Committed By: nia
Date: Sat Mar 12 08:36:52 UTC 2022
Modified Files:
src/lib/libc/stdio: vfwprintf.c
Log Message:
vfwprintf(3): use reallocarr
To generate a diff of this commit:
cvs rdiff -u -r1.36 -r1.37 src/lib/libc/stdio/vfwprintf.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: src/lib/libc/stdio/vfwprintf.c
diff -u src/lib/libc/stdio/vfwprintf.c:1.36 src/lib/libc/stdio/vfwprintf.c:1.37
--- src/lib/libc/stdio/vfwprintf.c:1.36 Tue Jul 11 19:36:38 2017
+++ src/lib/libc/stdio/vfwprintf.c Sat Mar 12 08:36:52 2022
@@ -1,4 +1,4 @@
-/* $NetBSD: vfwprintf.c,v 1.36 2017/07/11 19:36:38 perseant Exp $ */
+/* $NetBSD: vfwprintf.c,v 1.37 2022/03/12 08:36:52 nia Exp $ */
/*-
* Copyright (c) 1990, 1993
@@ -38,7 +38,7 @@
static char sccsid[] = "@(#)vfprintf.c 8.1 (Berkeley) 6/4/93";
__FBSDID("$FreeBSD: src/lib/libc/stdio/vfwprintf.c,v 1.27 2007/01/09 00:28:08 imp Exp $");
#else
-__RCSID("$NetBSD: vfwprintf.c,v 1.36 2017/07/11 19:36:38 perseant Exp $");
+__RCSID("$NetBSD: vfwprintf.c,v 1.37 2022/03/12 08:36:52 nia Exp $");
#endif
#endif /* LIBC_SCCS and not lint */
@@ -459,9 +459,11 @@ __mbsconv(char *mbsarg, int prec, locale
* converting at most `size' bytes of the input multibyte string to
* wide characters for printing.
*/
- convbuf = malloc((insize + 1) * sizeof(*convbuf));
- if (convbuf == NULL)
+ convbuf = NULL;
+ if (reallocarr(, insize + 1, sizeof(*convbuf)) != 0) {
+ errno = ENOMEM;
return NULL;
+ }
wcp = convbuf;
p = mbsarg;
mbs = initial;
@@ -1976,12 +1978,16 @@ __grow_type_table (size_t nextarg, enum
if (newsize < nextarg + 1)
newsize = nextarg + 1;
if (oldsize == STATIC_ARG_TBL_SIZE) {
- if ((newtable = malloc(newsize * sizeof(*newtable))) == NULL)
+ newtable = NULL;
+ if (reallocarr(, newsize, sizeof(*newtable)) != 0) {
+ errno = ENOMEM;
return -1;
+ }
memcpy(newtable, oldtable, oldsize * sizeof(*newtable));
} else {
- newtable = realloc(oldtable, newsize * sizeof(*newtable));
- if (newtable == NULL) {
+ newtable = oldtable;
+ if (reallocarr(, newsize, sizeof(*newtable)) != 0) {
+ errno = ENOMEM;
free(oldtable);
return -1;
}
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: nia Date: Sat Mar 12 08:36:52 UTC 2022 Modified Files: src/lib/libc/stdio: vfwprintf.c Log Message: vfwprintf(3): use reallocarr To generate a diff of this commit: cvs rdiff -u -r1.36 -r1.37 src/lib/libc/stdio/vfwprintf.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: kim Date: Thu Oct 28 09:51:39 UTC 2021 Modified Files: src/lib/libc/stdio: mktemp.3 Log Message: Use .Sq instead of a dangling .So To generate a diff of this commit: cvs rdiff -u -r1.31 -r1.32 src/lib/libc/stdio/mktemp.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: kim Date: Thu Oct 28 09:51:39 UTC 2021 Modified Files: src/lib/libc/stdio: mktemp.3 Log Message: Use .Sq instead of a dangling .So To generate a diff of this commit: cvs rdiff -u -r1.31 -r1.32 src/lib/libc/stdio/mktemp.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/mktemp.3 diff -u src/lib/libc/stdio/mktemp.3:1.31 src/lib/libc/stdio/mktemp.3:1.32 --- src/lib/libc/stdio/mktemp.3:1.31 Sun Jul 25 08:52:03 2021 +++ src/lib/libc/stdio/mktemp.3 Thu Oct 28 09:51:39 2021 @@ -1,4 +1,4 @@ -.\" $NetBSD: mktemp.3,v 1.31 2021/07/25 08:52:03 simonb Exp $ +.\" $NetBSD: mktemp.3,v 1.32 2021/10/28 09:51:39 kim Exp $ .\" .\" Copyright (c) 1989, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -66,24 +66,24 @@ to create a file name. This file name is unique and suitable for use by the application. The template may be any file name with some number of -.So Li X +.Sq Li X characters appended to it, for example .Pa /tmp/temp.XX . The trailing -.So Li X +.Sq Li X characters in the template are replaced with a unique letter and number combination. .Fn mktemp can return depends on the number of -.So Li X +.Sq Li X characters provided. Although the .Nx implementation of the functions will accept any number of trailing -.So Li X +.Sq Li X characters, for portability reasons one should use only six. Using six -.So Li X +.Sq Li X characters will result in .Fn mktemp testing roughly 62 ** 6 (56800235584) combinations.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: wiz Date: Thu Sep 23 12:17:57 UTC 2021 Modified Files: src/lib/libc/stdio: printf.3 Log Message: printf(3): mention snprintb(3) To generate a diff of this commit: cvs rdiff -u -r1.69 -r1.70 src/lib/libc/stdio/printf.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/printf.3 diff -u src/lib/libc/stdio/printf.3:1.69 src/lib/libc/stdio/printf.3:1.70 --- src/lib/libc/stdio/printf.3:1.69 Tue Feb 16 14:44:25 2021 +++ src/lib/libc/stdio/printf.3 Thu Sep 23 12:17:57 2021 @@ -1,4 +1,4 @@ -.\" $NetBSD: printf.3,v 1.69 2021/02/16 14:44:25 riastradh Exp $ +.\" $NetBSD: printf.3,v 1.70 2021/09/23 12:17:57 wiz Exp $ .\" .\" Copyright (c) 1990, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -811,6 +811,7 @@ or the return value would be too large t .Xr fmtcheck 3 , .Xr scanf 3 , .Xr setlocale 3 , +.Xr snprintb 3 , .Xr wprintf 3 , .Xr printf 9 .Sh STANDARDS
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: wiz Date: Thu Sep 23 12:17:57 UTC 2021 Modified Files: src/lib/libc/stdio: printf.3 Log Message: printf(3): mention snprintb(3) To generate a diff of this commit: cvs rdiff -u -r1.69 -r1.70 src/lib/libc/stdio/printf.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: rillig Date: Sat Sep 11 18:46:22 UTC 2021 Modified Files: src/lib/libc/stdio: fseek.3 Log Message: fseek.3: fix grammar To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29 src/lib/libc/stdio/fseek.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/fseek.3 diff -u src/lib/libc/stdio/fseek.3:1.28 src/lib/libc/stdio/fseek.3:1.29 --- src/lib/libc/stdio/fseek.3:1.28 Sun Jan 1 12:39:33 2017 +++ src/lib/libc/stdio/fseek.3 Sat Sep 11 18:46:22 2021 @@ -1,4 +1,4 @@ -.\" $NetBSD: fseek.3,v 1.28 2017/01/01 12:39:33 abhinav Exp $ +.\" $NetBSD: fseek.3,v 1.29 2021/09/11 18:46:22 rillig Exp $ .\" .\" Copyright (c) 1990, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -33,7 +33,7 @@ .\" .\" @(#)fseek.3 8.1 (Berkeley) 6/4/93 .\" -.Dd January 1, 2017 +.Dd September 11, 2021 .Dt FSEEK 3 .Os .Sh NAME @@ -130,7 +130,7 @@ except that the error indicator for the In this implementations, .Dq Fa fpos_t is a complex object that represents both the position and the parse -state of the stream, making these routines as the only way to portably +state of the stream, making these routines the only way to portably reposition a text stream. The .Ar pos
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: rillig Date: Sat Sep 11 18:46:22 UTC 2021 Modified Files: src/lib/libc/stdio: fseek.3 Log Message: fseek.3: fix grammar To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29 src/lib/libc/stdio/fseek.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/lib/libc/stdio
Date:Mon, 1 Feb 2021 17:50:54 + From:"Jaromir Dolecek" Message-ID: <20210201175054.112e7f...@cvs.netbsd.org> | FreeBSD has a similar check, but they return EINVAL instead, feel | free to adjust if SUS or other standard mandates specific value Not currently (unless the C standard says something) - but EINVAL would be a better choice, fread() incorporates all errors from fgetc() (and fwrite() from fputc()) and there EOVERFLOW is used to indicate that the file offset exceeds the maximum possible file size, which is quite a different problem. EINVAL is currently unused (at least in POSIX) but makes more sense for this problem (which is am invalid arg combination). FWIW, I submitted a defect report on this issue with the Austin Group (POSIX maintainers) yesterday, though I am expecting they'll simply punt it to the C standards group. kre
Re: CVS commit: src/lib/libc/stdio
Date:Sun, 31 Jan 2021 18:34:22 +0100 From:Joerg Sonnenberger Message-ID: | That makes no sense. Just turn them into a short read, which is | something users have to deal with anyway. I'm not sure I agree with that one. If the user's size * nmemb overflows a size_t then the user is attempting something entirely insane (they cannot possibly have a buffer that big). Reading anything at all is most probably the wrong thing to do, as the args are very likely simply erroneous. EINVAL is not an unreasonable approach, I wouldn't even object to simply abort(). kre
Re: CVS commit: src/lib/libc/stdio
On 31.01.2021 18:34, Joerg Sonnenberger wrote: > On Sun, Jan 31, 2021 at 05:27:28PM +0100, Kamil Rytarowski wrote: >> On 31.01.2021 17:18, Jaromir Dolecek wrote: >>> Module Name:src >>> Committed By: jdolecek >>> Date: Sun Jan 31 16:18:22 UTC 2021 >>> >>> Modified Files: >>> src/lib/libc/stdio: fread.c >>> >>> Log Message: >>> for unbuffered I/O arrange for the destination buffer to be filled in one >>> go, instead of triggering long series of 1 byte read(2)s; this speeds up >>> fread() several order of magnitudes for this case, directly proportional >>> to the size of the supplied buffer >>> >>> change adapted from OpenBSD rev. 1.19 >>> >>> fixes PR lib/55808 by Roland Illig >>> >> >> While there it would be cool to apply FreeBSD and OpenBSD hardening for >> invalid size x nmemb, checking for overflow. I propose to return EINVAL >> in such case. > > That makes no sense. Just turn them into a short read, which is > something users have to deal with anyway. > > Joerg > The purpose of this errno is to catch insage usage of API that in normal circumstances never makes sense. With overflows (that are fine), the error can be unnoticed. Both FreeBSD and OpenBSD found this behavior as useful.
Re: CVS commit: src/lib/libc/stdio
On Sun, Jan 31, 2021 at 05:27:28PM +0100, Kamil Rytarowski wrote: > On 31.01.2021 17:18, Jaromir Dolecek wrote: > > Module Name:src > > Committed By: jdolecek > > Date: Sun Jan 31 16:18:22 UTC 2021 > > > > Modified Files: > > src/lib/libc/stdio: fread.c > > > > Log Message: > > for unbuffered I/O arrange for the destination buffer to be filled in one > > go, instead of triggering long series of 1 byte read(2)s; this speeds up > > fread() several order of magnitudes for this case, directly proportional > > to the size of the supplied buffer > > > > change adapted from OpenBSD rev. 1.19 > > > > fixes PR lib/55808 by Roland Illig > > > > While there it would be cool to apply FreeBSD and OpenBSD hardening for > invalid size x nmemb, checking for overflow. I propose to return EINVAL > in such case. That makes no sense. Just turn them into a short read, which is something users have to deal with anyway. Joerg
Re: CVS commit: src/lib/libc/stdio
On 31.01.2021 17:18, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Sun Jan 31 16:18:22 UTC 2021 > > Modified Files: > src/lib/libc/stdio: fread.c > > Log Message: > for unbuffered I/O arrange for the destination buffer to be filled in one > go, instead of triggering long series of 1 byte read(2)s; this speeds up > fread() several order of magnitudes for this case, directly proportional > to the size of the supplied buffer > > change adapted from OpenBSD rev. 1.19 > > fixes PR lib/55808 by Roland Illig > While there it would be cool to apply FreeBSD and OpenBSD hardening for invalid size x nmemb, checking for overflow. I propose to return EINVAL in such case. I planned to submit it a while ago for discussion.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Sat Sep 7 11:53:27 UTC 2019 Modified Files: src/lib/libc/stdio: fflush.3 Log Message: Document history To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/lib/libc/stdio/fflush.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Sat Sep 7 11:53:27 UTC 2019 Modified Files: src/lib/libc/stdio: fflush.3 Log Message: Document history To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/lib/libc/stdio/fflush.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/fflush.3 diff -u src/lib/libc/stdio/fflush.3:1.12 src/lib/libc/stdio/fflush.3:1.13 --- src/lib/libc/stdio/fflush.3:1.12 Thu Aug 7 16:43:22 2003 +++ src/lib/libc/stdio/fflush.3 Sat Sep 7 11:53:27 2019 @@ -1,4 +1,4 @@ -.\" $NetBSD: fflush.3,v 1.12 2003/08/07 16:43:22 agc Exp $ +.\" $NetBSD: fflush.3,v 1.13 2019/09/07 11:53:27 sevan Exp $ .\" .\" Copyright (c) 1990, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -33,7 +33,7 @@ .\" .\" @(#)fflush.3 8.1 (Berkeley) 6/4/93 .\" -.Dd June 4, 1993 +.Dd September 7, 2019 .Dt FFLUSH 3 .Os .Sh NAME @@ -108,3 +108,12 @@ The function conforms to .St -ansiC . +.Sh HISTORY +The +.Fn fflush +function first appeared in +.At v4 . +The +.Fn fpurge +function first appeared in +.Bx 4.4 .
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Mon Sep 2 00:48:16 UTC 2019 Modified Files: src/lib/libc/stdio: putc.3 Log Message: putc & putw were in v1 https://www.bell-labs.com/usr/dmr/www/man31.pdf putchar was in v4 https://minie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man3/putchr.3 To generate a diff of this commit: cvs rdiff -u -r1.13 -r1.14 src/lib/libc/stdio/putc.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/putc.3 diff -u src/lib/libc/stdio/putc.3:1.13 src/lib/libc/stdio/putc.3:1.14 --- src/lib/libc/stdio/putc.3:1.13 Wed Feb 22 15:08:55 2017 +++ src/lib/libc/stdio/putc.3 Mon Sep 2 00:48:16 2019 @@ -1,4 +1,4 @@ -.\" $NetBSD: putc.3,v 1.13 2017/02/22 15:08:55 abhinav Exp $ +.\" $NetBSD: putc.3,v 1.14 2019/09/02 00:48:16 sevan Exp $ .\" .\" Copyright (c) 1990, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -33,7 +33,7 @@ .\" .\" @(#)putc.3 8.1 (Berkeley) 6/4/93 .\" -.Dd May 6, 2010 +.Dd September 2, 2019 .Dt PUTC 3 .Os .Sh NAME @@ -152,13 +152,16 @@ and conform to .St -p1003.1-96 . .Sh HISTORY -The functions +The .Fn putc , -.Fn putchar , and .Fn putw -first appeared in -.At v6 . +functions first appeared in +.At v1 . +The +.Fn putchar +function first appeared in +.At v4 . The function .Fn fputc appeared in
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Mon Sep 2 00:48:16 UTC 2019 Modified Files: src/lib/libc/stdio: putc.3 Log Message: putc & putw were in v1 https://www.bell-labs.com/usr/dmr/www/man31.pdf putchar was in v4 https://minie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man3/putchr.3 To generate a diff of this commit: cvs rdiff -u -r1.13 -r1.14 src/lib/libc/stdio/putc.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Mon Sep 2 00:32:55 UTC 2019 Modified Files: src/lib/libc/stdio: fopen.3 Log Message: Start documenting history https://www.bell-labs.com/usr/dmr/www/man31.pdf To generate a diff of this commit: cvs rdiff -u -r1.35 -r1.36 src/lib/libc/stdio/fopen.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/fopen.3 diff -u src/lib/libc/stdio/fopen.3:1.35 src/lib/libc/stdio/fopen.3:1.36 --- src/lib/libc/stdio/fopen.3:1.35 Sat Nov 4 08:53:23 2017 +++ src/lib/libc/stdio/fopen.3 Mon Sep 2 00:32:55 2019 @@ -1,4 +1,4 @@ -.\" $NetBSD: fopen.3,v 1.35 2017/11/04 08:53:23 kre Exp $ +.\" $NetBSD: fopen.3,v 1.36 2019/09/02 00:32:55 sevan Exp $ .\" .\" Copyright (c) 1990, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -33,7 +33,7 @@ .\" .\" @(#)fopen.3 8.1 (Berkeley) 6/4/93 .\" -.Dd November 3, 2017 +.Dd September 2, 2019 .Dt FOPEN 3 .Os .Sh NAME @@ -298,6 +298,11 @@ functions conform to .St -ansiC . All three functions are specified in .St -p1003.1-2008 . +.Sh HISTORY +An +.Fn fopen +function appeared in +.At v1 . .Sh CAVEATS Proper code using .Fn fdopen
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Mon Sep 2 00:32:55 UTC 2019 Modified Files: src/lib/libc/stdio: fopen.3 Log Message: Start documenting history https://www.bell-labs.com/usr/dmr/www/man31.pdf To generate a diff of this commit: cvs rdiff -u -r1.35 -r1.36 src/lib/libc/stdio/fopen.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Mon Sep 2 00:30:58 UTC 2019 Modified Files: src/lib/libc/stdio: getc.3 Log Message: Start documenting history https://www.bell-labs.com/usr/dmr/www/man31.pdf To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/lib/libc/stdio/getc.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: sevan Date: Mon Sep 2 00:30:58 UTC 2019 Modified Files: src/lib/libc/stdio: getc.3 Log Message: Start documenting history https://www.bell-labs.com/usr/dmr/www/man31.pdf To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/lib/libc/stdio/getc.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/getc.3 diff -u src/lib/libc/stdio/getc.3:1.12 src/lib/libc/stdio/getc.3:1.13 --- src/lib/libc/stdio/getc.3:1.12 Thu Aug 7 16:43:26 2003 +++ src/lib/libc/stdio/getc.3 Mon Sep 2 00:30:58 2019 @@ -1,4 +1,4 @@ -.\" $NetBSD: getc.3,v 1.12 2003/08/07 16:43:26 agc Exp $ +.\" $NetBSD: getc.3,v 1.13 2019/09/02 00:30:58 sevan Exp $ .\" .\" Copyright (c) 1990, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -33,7 +33,7 @@ .\" .\" @(#)getc.3 8.1 (Berkeley) 6/4/93 .\" -.Dd April 25, 2001 +.Dd September 2, 2019 .Dt GETC 3 .Os .Sh NAME @@ -154,6 +154,13 @@ and .Fn getchar_unlocked functions conform to .St -p1003.1-96 . +.Sh HISTORY +The +.Fn getc +and +.Fn getw +functions appeared in +.At v1 . .Sh BUGS Since .Dv EOF
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: uwe Date: Sun Sep 1 01:23:14 UTC 2019 Modified Files: src/lib/libc/stdio: tmpnam.3 Log Message: Refer to "w+" as "mode" as that's what fopen(3) calls it. To generate a diff of this commit: cvs rdiff -u -r1.17 -r1.18 src/lib/libc/stdio/tmpnam.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
CVS commit: src/lib/libc/stdio
Module Name:src Committed By: uwe Date: Sun Sep 1 01:23:14 UTC 2019 Modified Files: src/lib/libc/stdio: tmpnam.3 Log Message: Refer to "w+" as "mode" as that's what fopen(3) calls it. To generate a diff of this commit: cvs rdiff -u -r1.17 -r1.18 src/lib/libc/stdio/tmpnam.3 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. Modified files: Index: src/lib/libc/stdio/tmpnam.3 diff -u src/lib/libc/stdio/tmpnam.3:1.17 src/lib/libc/stdio/tmpnam.3:1.18 --- src/lib/libc/stdio/tmpnam.3:1.17 Fri Apr 30 04:55:10 2010 +++ src/lib/libc/stdio/tmpnam.3 Sun Sep 1 01:23:14 2019 @@ -1,4 +1,4 @@ -.\" $NetBSD: tmpnam.3,v 1.17 2010/04/30 04:55:10 jruoho Exp $ +.\" $NetBSD: tmpnam.3,v 1.18 2019/09/01 01:23:14 uwe Exp $ .\" .\" Copyright (c) 1988, 1991, 1993 .\" The Regents of the University of California. All rights reserved. @@ -62,7 +62,7 @@ The created file is unlinked before .Fn tmpfile returns, causing the file to be automatically deleted when the last reference to it is closed. -The file is opened with the access value +The file is opened with the access mode .Ql w+ . .Pp The
Re: CVS commit: src/lib/libc/stdio
On Mon, Sep 29, 2014 at 09:35:04PM +0200, Steffen Nurpmeso wrote: Not being able to get to the list of pull-ups from that page, or at least getting a hint of where to find them is... a mistake. I wouldn't call it a mistake (though links certainly can be added) - that page documents something completely different. And I'm also not sure how usefull the queue (open tickets) or the list of resolved tickets would be. What would be really usefull would be a link in the source-changes email, pointing to cvsweb (or whatever), and that showing pullup state for each individual source change ;-) Another topic, slightly orthogonal, is: how can we improve the google hits for various of the dynamic pages on releng.netbsd.org. Martin
Re: CVS commit: src/lib/libc/stdio
Martin Husemann mar...@duskware.de wrote: |On Mon, Sep 29, 2014 at 09:35:04PM +0200, Steffen Nurpmeso wrote: | Not being able to get to the list of pull-ups from that page, or | at least getting a hint of where to find them is... a mistake. | |I wouldn't call it a mistake (though links certainly can be added) - |that page documents something completely different. And I'm also not |sure how usefull the queue (open tickets) or the list of resolved |tickets would be. Can be added, right. Should be added for those who are not familiar with internals, since such a person is pretty lost. E.g., there are Sushi let me say artists which can prepare a fish in such a way that she or he is still breathing whereas anything behind the head is prepared for eating. By non-vegetarians, that is. Christs may also ask if all that is necessary if there is Jesus? |What would be really usefull would be a link in the source-changes email, |pointing to cvsweb (or whatever), and that showing pullup state for each |individual source change ;-) I finally found a project that uses the automatic notification mechanism that i thought (long ago that) OpenBSD implemented for maintaining their plus.html: Crux Linux commit messages can be tagged for at least security notifications, which then get mailed out automatically. (On the other hand it is quite boring, chromium, firefox, flash-player, php, dhcpcd ... the usual suspects.) |Another topic, slightly orthogonal, is: how can we improve the google |hits for various of the dynamic pages on releng.netbsd.org. That is beyond my understanding. --steffen
Re: CVS commit: src/lib/libc/stdio
On Mon, Sep 29, 2014 at 08:29:10PM +0200, Steffen Nurpmeso wrote: (And also i would place a link to the current pull-ups (to the wiki) on www.netbsd.org/developers/releng/pullups.html, since Google shows the latter first, yet that is astonishing empty.) Can you say that again, please? Martin
Re: CVS commit: src/lib/libc/stdio
|Module Name: src |Committed By: christos |Date: Mon Sep 29 14:58:33 UTC 2014 | |Modified Files: | src/lib/libc/stdio: printf.3 vsnprintf.c vsnprintf_ss.c | |Log Message: |Return EOVERFLOW like FreeBSD does if the buffer size exceeds INT_MAX |(well FreeBSD documents INT_MAX + 1, but in the code it is INT_MAX). I would pull up that. (Just in case i get 6.1.4 installed and then - later - upgraded.) (And also i would place a link to the current pull-ups (to the wiki) on www.netbsd.org/developers/releng/pullups.html, since Google shows the latter first, yet that is astonishing empty.) --steffen
Re: CVS commit: src/lib/libc/stdio
On Mon, 29 Sep 2014, Martin Husemann wrote: On Mon, Sep 29, 2014 at 08:29:10PM +0200, Steffen Nurpmeso wrote: (And also i would place a link to the current pull-ups (to the wiki) on www.netbsd.org/developers/releng/pullups.html, since Google shows the latter first, yet that is astonishing empty.) Can you say that again, please? I think he means: Please add links from http://www.netbsd.org/developers/releng/pullups.html to https://releng.netbsd.org/index-7.html, https://releng.netbsd.org/index-6.html, and https://releng.netbsd.org/index-5.html. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/stdio
Martin Husemann mar...@duskware.de wrote: |On Mon, Sep 29, 2014 at 08:29:10PM +0200, Steffen Nurpmeso wrote: | (And also i would place a link to the current pull-ups (to the | wiki) on www.netbsd.org/developers/releng/pullups.html, since | Google shows the latter first, yet that is astonishing empty.) | |Can you say that again, please? Not being able to get to the list of pull-ups from that page, or at least getting a hint of where to find them is... a mistake. --steffen
Re: CVS commit: src/lib/libc/stdio
Hi, It seems that lint(1) is not cross build safe, it doesn't handle MD char default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon(). They use host MD CHAR_MAX directry ;) So, if cross building ppc/arm on other arch cause false alarm , out of range warnng. Regards. -- 2012/03/22 10:39 Joerg Sonnenberger jo...@britannica.bec.de: On Thu, Mar 22, 2012 at 01:31:41AM +, Christos Zoulas wrote: In article 20120322003141.gb1...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Mar 21, 2012 at 10:20:47AM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed Mar 21 14:20:47 UTC 2012 Modified Files: src/lib/libc/stdio: vfwprintf.c Log Message: unsigned char portability casts This looks wrong. What's the point of it? What's is wrong with it? It should be unnecessary. CHAR_MAX is certainly required to fit into both char and unsigned char. Joerg
Re: CVS commit: src/lib/libc/stdio
On Tue, Mar 27, 2012 at 20:19:41 +, Christos Zoulas wrote: In article CAN6pqGQMV-JtfuidyRAH1VoYV7mJott=aruq3t3nro1kwcd...@mail.gmail.com, Takehiko NOZAKI takehiko.noz...@gmail.com wrote: -=-=-=-=-=- Hi, It seems that lint(1) is not cross build safe, it doesn't handle MD char default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon(). They use host MD CHAR_MAX directry ;) So, if cross building ppc/arm on other arch cause false alarm , out of range warnng. It is not out of range warning, it is: nonportable character comparison, op %s,/* 230 */ the question is if 'char c; if (c == 255)' is portable or not. But that is not what the code was. The code was: char c; if (c == CHAR_MAX) ... and *that* is portable. As I said in another mail to thsi thread that went unanswered, it is literally schizophrenic of lint to complain about it. I used to be on the fence about lint, leaning more towards favorable side. But recent rounds of lint induced churn made me change my mind. -uwe
Re: CVS commit: src/lib/libc/stdio
In article 20120327202907.gt26...@bigmac.stderr.spb.ru, Valeriy E. Ushakov u...@stderr.spb.ru wrote: But that is not what the code was. The code was: char c; if (c == CHAR_MAX) ... and *that* is portable. As I said in another mail to thsi thread that went unanswered, it is literally schizophrenic of lint to complain about it. How can lint know that if (c == 255) is portable? Because CHAR_MAX gets expanded by cpp to 255 before lint parses the file. christos
Re: CVS commit: src/lib/libc/stdio
On 28 March 2012 07:53, Christos Zoulas chris...@astron.com wrote: In article 20120327202907.gt26...@bigmac.stderr.spb.ru, Valeriy E. Ushakov u...@stderr.spb.ru wrote: But that is not what the code was. The code was: char c; if (c == CHAR_MAX) ... and *that* is portable. As I said in another mail to thsi thread that went unanswered, it is literally schizophrenic of lint to complain about it. How can lint know that if (c == 255) is portable? Because CHAR_MAX gets expanded by cpp to 255 before lint parses the file. (How) does the compiler (not) catch this one ? -- ~Cherry
Re: CVS commit: src/lib/libc/stdio
In article 20120322003141.gb1...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Mar 21, 2012 at 10:20:47AM -0400, Christos Zoulas wrote: Module Name: src Committed By:christos Date:Wed Mar 21 14:20:47 UTC 2012 Modified Files: src/lib/libc/stdio: vfwprintf.c Log Message: unsigned char portability casts This looks wrong. What's the point of it? What's is wrong with it? christos
Re: CVS commit: src/lib/libc/stdio
On Thu, Mar 22, 2012 at 01:31:41AM +, Christos Zoulas wrote: In article 20120322003141.gb1...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Wed, Mar 21, 2012 at 10:20:47AM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Wed Mar 21 14:20:47 UTC 2012 Modified Files: src/lib/libc/stdio: vfwprintf.c Log Message: unsigned char portability casts This looks wrong. What's the point of it? What's is wrong with it? It should be unnecessary. CHAR_MAX is certainly required to fit into both char and unsigned char. Joerg
Re: CVS commit: src/lib/libc/stdio
Hi, It seems that lint(1) is not cross build safe, it doesn't handle MD char default type of sign/unsignd. See src/usr.bin/xlint/lint1/tree.c::cvtcon(). They use host MD CHAR_MAX directry ;) So, if cross building ppc/arm on other arch cause false alarm , out of range warnng. very truly yours. -- Takehiko NOZAKItnoz...@netbsd.org 2012/3/21 Christos Zoulas chris...@netbsd.org: Module Name: src Committed By: christos Date: Wed Mar 21 14:20:47 UTC 2012 Modified Files: src/lib/libc/stdio: vfwprintf.c Log Message: unsigned char portability casts To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29 src/lib/libc/stdio/vfwprintf.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/lib/libc/stdio
Hi, 2012/2/18 Christos Zoulas chris...@netbsd.org: Module Name: src Committed By: christos Date: Fri Feb 17 19:57:53 UTC 2012 Modified Files: src/lib/libc/stdio: vfwprintf.c Log Message: Fix: CVE-2012-0864 fprintf() positional argument abuse. Described in: http://www.phrack.org/issues.html?issue=67id=9#article Reported by Stefan Cornelius / Red Hat Security Response Team - convert internal positional arguments bookkeeping from int to size_t - provide overflow protection in positional argument spec - convert loops to memset - fix memory leaks - limit positional argument stack offset to the number of arguments required by the printf to avoid coredump from va_arg() exhaustion. # compile libc/vfprintf.ln CC=/usr/local/netbsd-tools/i386/bin/i686--netbsdelf-gcc /usr/local/netbsd-tools/i386/bin/i686--netbsdelf-lint -chapbxzFS -w -X 272 -d /home/snapshot/20120217/root/i386/usr/include -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -DHESIOD -DINET6 -DNLS -DYP -I/usr/src/lib/libc/include -I/usr/src/lib/libc -I/usr/src/sys -I/usr/src/lib/libc/compat/../locale -I/usr/src/lib/libc/compat/stdlib -I/usr/src/lib/libc/compat/../stdlib -I/usr/src/lib/libc/../../common/lib/libc/quad -I/usr/src/lib/libc/../../common/lib/libc/string -I/usr/src/lib/libc/../../common/lib/libc/arch/i386/string -D__DBINTERFACE_PRIVATE -I/usr/src/libexec/ld.elf_so -I/usr/src/lib/libc/dlfcn -I/usr/src/lib/libc/gdtoa -DNO_FENV_H -I/usr/src/lib/libc/arch/i386/gdtoa -DWITH_RUNE -I/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL -DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT -D_FORTIFY_SOURCE=2-i /usr/src/lib/libc/stdio/vfprintf.c /usr/src/lib/libc/stdio/vfwprintf.c(1934): warning: n unused in function __grow_type_table [192] *** Failed target: vfprintf.ln *** Failed command: CC=/usr/local/netbsd-tools/i386/bin/i686--netbsdelf-gcc /usr/local/netbsd-tools/i386/bin/i686--netbsdelf-lint -chapbxzFS -w -X 272 -d /home/snapshot/20120217/root/i386/usr/include -D_LIBC -DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -DHESIOD -DINET6 -DNLS -DYP -I/usr/src/lib/libc/include -I/usr/src/lib/libc -I/usr/src/sys -I/usr/src/lib/libc/compat/../locale -I/usr/src/lib/libc/compat/stdlib -I/usr/src/lib/libc/compat/../stdlib -I/usr/src/lib/libc/../../common/lib/libc/quad -I/usr/src/lib/libc/../../common/lib/libc/string -I/usr/src/lib/libc/../../common/lib/libc/arch/i386/string -D__DBINTERFACE_PRIVATE -I/usr/src/libexec/ld.elf_so -I/usr/src/lib/libc/dlfcn -I/usr/src/lib/libc/gdtoa -DNO_FENV_H -I/usr/src/lib/libc/arch/i386/gdtoa -DWITH_RUNE -I/usr/src/lib/libc -DPOSIX_MISTAKE -DCOMPAT__RES -DUSE_POLL -DPORTMAP -DWIDE_DOUBLE -DALL_STATE -DUSG_COMPAT -D_FORTIFY_SOURCE=2 -i /usr/src/lib/libc/stdio/vfprintf.c *** Error code 1 Stop. nbmake: stopped in /usr/src/lib/libc Regards, -- NONAKA Kimihiro
Re: CVS commit: src/lib/libc/stdio
On Mon, Sep 12, 2011 at 02:41:07AM +, David Holland wrote: On Sun, Sep 11, 2011 at 07:37:06AM +, Jukka Ruohonen wrote: Modified Files: src/lib/libc/stdio: funopen.3 Log Message: It is not just funopen(3) that is a BSDism. While that's true, those functions aren't specific to .Nx; AFAIK they were in 4.4. True enough. But I've generally followed NetBSD-specific vs. standard dichotomy. In the ideal case one could mention if a function is available in OpenBSD, FreeBSD, Solaris, Linux, etc. too, but we have enough trouble maintaining .Nx alone. - Jukka.
Re: CVS commit: src/lib/libc/stdio
Date:Sun, 24 Oct 2010 16:00:46 +0100 From:Matthias Scheler t...@netbsd.org Message-ID: 20101024150046.ga...@colwyn.zhadum.org.uk | It doesn't have to be a macro anyway as it used only ones. Yes, I meant to ask about that, simply written inline would be no problem. kre
Re: CVS commit: src/lib/libc/stdio
On Mon, Oct 25, 2010 at 12:24:14AM +0700, Robert Elz wrote: Date:Sun, 24 Oct 2010 16:00:46 +0100 From:Matthias Scheler t...@netbsd.org Message-ID: 20101024150046.ga...@colwyn.zhadum.org.uk | It doesn't have to be a macro anyway as it used only ones. Yes, I meant to ask about that, simply written inline would be no problem. That's what I've done now. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libc/stdio
On Fri, Oct 22, 2010 at 05:29:46PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Fri Oct 22 21:29:46 UTC 2010 Modified Files: src/lib/libc/stdio: ftell.c local.h Log Message: implement EOVERFLOW To generate a diff of this commit: cvs rdiff -u -r1.15 -r1.16 src/lib/libc/stdio/ftell.c cvs rdiff -u -r1.25 -r1.26 src/lib/libc/stdio/local.h This breaks with: /usr/src/lib/libc/stdio/ftell.c(100): warning: constant in conditional context [161] *** Failed target: ftell.ln - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Sat, Oct 23, 2010 at 10:12:51AM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Sat Oct 23 14:12:51 UTC 2010 Modified Files: src/lib/libc/stdio: local.h Log Message: tell lint to shut up. I'm sorry but this whole code is horrible. What is wrong with something as simple as this? Index: local.h === RCS file: /cvsroot/src/lib/libc/stdio/local.h,v retrieving revision 1.28 diff -u -r1.28 local.h --- local.h 23 Oct 2010 14:12:50 - 1.28 +++ local.h 23 Oct 2010 15:10:27 - @@ -37,6 +37,8 @@ #include wcio.h #include fileext.h +#include limits.h + /* * Information local to this implementation of stdio, * in particular, macros and private variables. @@ -117,5 +119,4 @@ /* * Detect if the current file position fits in a long int. */ -#define _FPOS_OVERFLOW(pos) (/*CONSTCOND*/sizeof(fpos_t) sizeof(long) \ - ((pos) (~0ULL ((sizeof(fpos_t) - sizeof(long)) * NBBY))) != 0) +#define _FPOS_OVERFLOW(pos) ((pos) LONG_MIN || (pos) LONG_MAX) It works fine under NetBSD/i386 and builts fine for NetBSD/amd64. And I would hope that the compiler is clever anough to optimize the code away on 64bit platforms. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libc/stdio
On Tue, Sep 28, 2010 at 11:06:39AM +0900, Masao Uebayashi wrote:
Index: src/lib/libc/stdio/fmemopen.c
diff -u src/lib/libc/stdio/fmemopen.c:1.3 src/lib/libc/stdio/fmemopen.c:1.4
--- src/lib/libc/stdio/fmemopen.c:1.3 Sat Sep 25 14:00:30 2010
+++ src/lib/libc/stdio/fmemopen.c Mon Sep 27 16:50:13 2010
@@ -79,16 +79,18 @@
if (p-cur = p-tail)
return 0;
s = p-cur;
- t = p-tail - 1;
do {
- if (p-cur == t) {
- if (*buf == '\0')
- *p-cur++ = *buf++;
+ if (p-cur == p-tail - 1) {
+ if (*buf == '\0') {
+ *p-cur++ = '\0';
+ goto ok;
+ }
break;
}
*p-cur++ = *buf++;
} while (--nbytes 0);
*p-cur = '\0';
+ok:
if (p-cur p-eob)
p-eob = p-cur;
Do we have any reason to NOT use more assertions in such a critical
library code path?
I'm not sure how fmemopen(3) qualifies as a critical library code path,
but, whatever.
As for more and more assertions - if people remember the bind assertion
fun we had in July 2009, then I'm sure there would be people asking for
less assertions, not more, especially in library code.
By all means check and warn, but please do not cause execution to halt
unless it's absolutely essential.
Regards,
Alistair
Re: CVS commit: src/lib/libc/stdio
On Tue, Sep 28, 2010 at 08:28:04AM +0200, Alistair Crooks wrote:
On Tue, Sep 28, 2010 at 11:06:39AM +0900, Masao Uebayashi wrote:
Index: src/lib/libc/stdio/fmemopen.c
diff -u src/lib/libc/stdio/fmemopen.c:1.3
src/lib/libc/stdio/fmemopen.c:1.4
--- src/lib/libc/stdio/fmemopen.c:1.3 Sat Sep 25 14:00:30 2010
+++ src/lib/libc/stdio/fmemopen.c Mon Sep 27 16:50:13 2010
@@ -79,16 +79,18 @@
if (p-cur = p-tail)
return 0;
s = p-cur;
- t = p-tail - 1;
do {
- if (p-cur == t) {
- if (*buf == '\0')
- *p-cur++ = *buf++;
+ if (p-cur == p-tail - 1) {
+ if (*buf == '\0') {
+ *p-cur++ = '\0';
+ goto ok;
+ }
break;
}
*p-cur++ = *buf++;
} while (--nbytes 0);
*p-cur = '\0';
+ok:
if (p-cur p-eob)
p-eob = p-cur;
Do we have any reason to NOT use more assertions in such a critical
library code path?
I'm not sure how fmemopen(3) qualifies as a critical library code path,
but, whatever.
I suppose all libc functions are critical. No idea how others think.
As for more and more assertions - if people remember the bind assertion
fun we had in July 2009, then I'm sure there would be people asking for
less assertions, not more, especially in library code.
By all means check and warn, but please do not cause execution to halt
unless it's absolutely essential.
I meant _DIAGASSERT(), which is expanded to real assert() iff DIAGNOSTIC
is defined. Assertions are to express code's intent.
Masao
Regards,
Alistair
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/lib/libc/stdio
Index: src/lib/libc/stdio/fmemopen.c
diff -u src/lib/libc/stdio/fmemopen.c:1.3 src/lib/libc/stdio/fmemopen.c:1.4
--- src/lib/libc/stdio/fmemopen.c:1.3 Sat Sep 25 14:00:30 2010
+++ src/lib/libc/stdio/fmemopen.c Mon Sep 27 16:50:13 2010
@@ -79,16 +79,18 @@
if (p-cur = p-tail)
return 0;
s = p-cur;
- t = p-tail - 1;
do {
- if (p-cur == t) {
- if (*buf == '\0')
- *p-cur++ = *buf++;
+ if (p-cur == p-tail - 1) {
+ if (*buf == '\0') {
+ *p-cur++ = '\0';
+ goto ok;
+ }
break;
}
*p-cur++ = *buf++;
} while (--nbytes 0);
*p-cur = '\0';
+ok:
if (p-cur p-eob)
p-eob = p-cur;
Do we have any reason to NOT use more assertions in such a critical
library code path?
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Re: CVS commit: src/lib/libc/stdio
On Fri, May 14, 2010 at 08:29:34AM +0300, Jukka Ruohonen wrote: Yes. The trouble is that because libraries and headers don't match up, you need to parse headers to extract the lists, and that seems likely to end up being delicate and a constant source of annoyance. How about the section 4 manual pages? Being systematically out-of-date, those are useful in a way that old phonebook might be useful. I believe Hubert extracted the supported chips via a script in iic(4). Although it captured a lot of devices that do not have a manual page, the idea is there. If it can be done reliably, it seems like a good idea. If it's not so reliable, crosschecking is better. Processing files.* with shell scripts is (for now at least), probably reliable; parsing C is less so... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 03:17:38PM +0300, Jukka Ruohonen wrote: Perhaps we need a bot to watch all commits and send reminders like You added a new file, but you haven't updated the sets, see URL for instructions, You added a new sysctl node but you haven't updated sysctl(7), etc. For this kind of stuff it should be easy enough to write some shell scripts that check consistency. A simple look should reveal the inconsistency. So the first approach sounds more fruitful. Perhaps, but lint scripts can look every night or whatever and it seems to me like a better choice. But to me, the problem is that we need a good amount of manual labour to keep those updated. Isn't this the kind of task where computers, not humans, are good at? As we've talked about history, it is worth to remember that those lists came from some early BSD where things were small and simple. Yes. The trouble is that because libraries and headers don't match up, you need to parse headers to extract the lists, and that seems likely to end up being delicate and a constant source of annoyance. A crosscheck will fail if something unexpected appears, which is more robust than trying to generate one from the other, where something unexpected will probably result in silently outputting nonsense. Anyway, can you (at your convenience) send me a list of the things like this that need consistency checking? I will then have a shot at writing some scripts and we can see what things look like. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Fri, May 14, 2010 at 05:10:24AM +, David Holland wrote: Anyway, can you (at your convenience) send me a list of the things like this that need consistency checking? I will then have a shot at writing some scripts and we can see what things look like. er wait, there's a list upthread. Is that all of them? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? ok, I think the conclusion is that this is a bug and it should set errno; now there's an implementation problem that it's a macro and stdio.h isn't allowed to include errno.h. I guess we can generate a third copy of the declaration of __errno, but I'd sort of rather not; it should really go in its own .h file somewhere, but we don't have a place for that (support/? bits/?) and adding one requires a bikeshedding round first. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Fri, May 14, 2010 at 05:10:24AM +, David Holland wrote: Yes. The trouble is that because libraries and headers don't match up, you need to parse headers to extract the lists, and that seems likely to end up being delicate and a constant source of annoyance. How about the section 4 manual pages? Being systematically out-of-date, those are useful in a way that old phonebook might be useful. I believe Hubert extracted the supported chips via a script in iic(4). Although it captured a lot of devices that do not have a manual page, the idea is there. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, 06 May 2010, Christos Zoulas wrote: The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? Our stdio supports funopen() which has FILE *'s where fileno() == -1, but they work just fine... This should be documented. Perhaps set errno if it is indeed a bad file descriptor, and don't set it if it is a side-effect of funopen()? It seems to me that funopen() creates a stream that is not associated with a file descriptor. I assume that's what POSIX meant by ... not associated with a file. So, I think that EBADF would be a reasonable response. Returning -1 without setting errno seems very wrong. Seting errno to some value that we think is more appropriate than EBADF would probably be OK. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/stdio
In article 20100507063258.ga23...@apb-laptoy.apb.alt.za, Alan Barrett a...@cequrux.com wrote: On Thu, 06 May 2010, Christos Zoulas wrote: The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? Our stdio supports funopen() which has FILE *'s where fileno() == -1, but they work just fine... This should be documented. Perhaps set errno if it is indeed a bad file descriptor, and don't set it if it is a side-effect of funopen()? It seems to me that funopen() creates a stream that is not associated with a file descriptor. I assume that's what POSIX meant by ... not associated with a file. So, I think that EBADF would be a reasonable response. Returning -1 without setting errno seems very wrong. Seting errno to some value that we think is more appropriate than EBADF would probably be OK. ENOTTY ;-) EOPNOTSUPP christos
Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 08:05:20AM +0200, Alan Barrett wrote: On Wed, 05 May 2010, Jukka Ruohonen wrote: Few examples of pages that are badly and *systematically* behind: intro(3) intro(4) pci(4) usb(4) mk.conf(5) sysctl(7) Perhaps we need a bot to watch all commits and send reminders like You added a new file, but you haven't updated the sets, see URL for instructions, You added a new sysctl node but you haven't updated sysctl(7), etc. For this kind of stuff it should be easy enough to write some shell scripts that check consistency. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? That it does not set the errno? Well, I am not the one who deals with libc, but personally I think strict conformance is not needed in a small detail like this, as long as it is documented behavior. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 12:04:53PM +0300, Jukka Ruohonen wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? That it does not set the errno? Well, I am not the one who deals with libc, but personally I think strict conformance is not needed in a small detail like this, as long as it is documented behavior. Actually, it is even optional. I fixed that. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 07:48:59AM +, David Holland wrote: On Wed, May 05, 2010 at 08:05:20AM +0200, Alan Barrett wrote: Perhaps we need a bot to watch all commits and send reminders like You added a new file, but you haven't updated the sets, see URL for instructions, You added a new sysctl node but you haven't updated sysctl(7), etc. For this kind of stuff it should be easy enough to write some shell scripts that check consistency. A simple look should reveal the inconsistency. So the first approach sounds more fruitful. But to me, the problem is that we need a good amount of manual labour to keep those updated. Isn't this the kind of task where computers, not humans, are good at? As we've talked about history, it is worth to remember that those lists came from some early BSD where things were small and simple. Though, once those have been undocumented or unmaintained for couple of years, it takes some detective work to figure out what all those knobs and switches are, and even then it may not be entirely clear. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. Joerg
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 02:48:32PM +0200, Joerg Sonnenberger wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. RETURN VALUE Upon successful completion, fileno() shall return the integer value of the file descriptor associated with stream. Otherwise, the value -1 shall be returned and errno set to indicate the error. ERRORS The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Thu, May 06, 2010 at 06:00:45PM +0300, Jukka Ruohonen wrote: On Thu, May 06, 2010 at 02:48:32PM +0200, Joerg Sonnenberger wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. RETURN VALUE Upon successful completion, fileno() shall return the integer value of the file descriptor associated with stream. Otherwise, the value -1 shall be returned and errno set to indicate the error. ERRORS The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? I don't mind if it sets errno, but I am not sure if POSIX makes a lot of sense here. But that's just me. Joerg
Re: CVS commit: src/lib/libc/stdio
On 6 May 2010, at 9:14, Jukka Ruohonen wrote: Module Name: src Committed By: jruoho Date: Thu May 6 08:14:08 UTC 2010 Modified Files: src/lib/libc/stdio: ferror.3 Log Message: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. Is there any reason not to make in compliant? It seems like a reasonable change. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libc/stdio
In article 20100506150045.ga...@marx.bitnet, Jukka Ruohonen jruoho...@iki.fi wrote: On Thu, May 06, 2010 at 02:48:32PM +0200, Joerg Sonnenberger wrote: On Thu, May 06, 2010 at 08:51:29AM +, David Holland wrote: On Thu, May 06, 2010 at 08:14:08AM +, Jukka Ruohonen wrote: Correct the discussion about return values: fileno() may fail and return -1. Note that in such cases the NetBSD implementation does not set errno to EBADF, hence diverging from the standard in this small detail. How is that not just a bug? -1 is a valid answer for not file-backed FILEs. I don't think it is an error. RETURN VALUE Upon successful completion, fileno() shall return the integer value of the file descriptor associated with stream. Otherwise, the value -1 shall be returned and errno set to indicate the error. ERRORS The fileno() function may fail if: [EBADF] The stream argument is not a valid stream, or the stream is not associated with a file. Isn't the above EBADF exactly what you are after? Our stdio supports funopen() which has FILE *'s where fileno() == -1, but they work just fine... This should be documented. Perhaps set errno if it is indeed a bad file descriptor, and don't set it if it is a side-effect of funopen()? christos
Re: CVS commit: src/lib/libc/stdio
On Wed, 05 May 2010, Jukka Ruohonen wrote: Few examples of pages that are badly and *systematically* behind: intro(3) intro(4) pci(4) usb(4) mk.conf(5) sysctl(7) Perhaps we need a bot to watch all commits and send reminders like You added a new file, but you haven't updated the sets, see URL for instructions, You added a new sysctl node but you haven't updated sysctl(7), etc. --apb (Alan Barrett)
Re: CVS commit: src/lib/libc/stdio
Jukka Ruohonen jruoho...@iki.fi wrote: On Wed, May 05, 2010 at 12:58:13AM +0700, Robert Elz wrote: | As something like gets() has been standardized for ages, it makes | sense to explicitly note that this may no longer be true (with | respect to POSIX). That's where I disagree, it is just bloat - once it stops being a standardised function, just stop calling it one. If the doc notes that fgets() is POSIX, and says nothing about gets(), the implication is quite clear, isn't it? I think the term bloat hardly ever applies to manual pages. If anything, they are often too terse. A paragraph or two about history or standards never hurts anyone. Two additional things: ... I think it does apply. Manual pages are something one works with, like a tool. Ability to easily and quickly find the information you need is an important factor. If you will write fairy-tales, that wont be convenient. That history will be in the CVS logs. That's enough for maintainers. For others reading the man page, this is all irrelevant (it would almost I think the history is relevant or at least interesting; one of the intriguing things about UNIX, really. History is indeed important, however it belongs to books, articles, etc. Other part of history belongs to version control logs, as Robert already mentioned. If I will want to figure out why and by whom some function was invented, how it looked originally, why it diverged, etc - CVS logs will likely answer that better, than a manual page. -- Mindaugas
Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 08:52:23AM +0100, Mindaugas Rasiukevicius wrote: History is indeed important, however it belongs to books, articles, etc. Other part of history belongs to version control logs, as Robert already mentioned. If I will want to figure out why and by whom some function was invented, how it looked originally, why it diverged, etc - CVS logs will likely answer that better, than a manual page. Round and round we go... The HISTORY and STANDARDS sections are typically only a single sentence long. Besides, you make it sound like I was the one who invented these. But long before NetBSD, someone at Berkeley decided that these were a good thing to have. I am merely following that tradition and updating these sections when seen as appropriate. I've already stated that it would be great to have published books and articles about NetBSD. This, however, is sadly very unrealistic already because there is no appropriate channels for such technical articles. Besides, telling someone to go write a book is counterproductive, to say the least. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 06:53:06AM +0300, Jukka Ruohonen wrote: Please revert this change. I will rever it. Can you change it to use .Xr please? That makes proper cross-references in HTML output possible. Joerg
Re: CVS commit: src/lib/libc/stdio
Date:Fri, 30 Apr 2010 06:00:14 + From:Jukka Ruohonen jru...@netbsd.org Message-ID: 20100430060014.7739117...@cvs.netbsd.org | Module Name:src | Committed By: jruoho | Date: Fri Apr 30 06:00:14 UTC 2010 | | Modified Files: | src/lib/libc/stdio: fgets.3 | | Log Message: | They've finally made gets(3) obsolete (in POSIX, at least). I don't understand the change - that is, I don't understand the sentence that was added to the man page, it says ... The revision marked gets() as obsolete... What revision??? The previous sentence just says that gets() (and fgets()) confirms with specific ANSI (C) and IEEE (Posix) standards. What's there now is just plain confusing. While I'm here, I would also note that it really makes no sense go racing about documenting things as not complying to some standard or other (by which I mean, that some function is not (or no longer) a standard function, as distinct from our implementation is different from the standard, which is definitely worthy of documentation.) We have LOTS of functions that aren't standardised anywhere, racing around saying they're not, helps no-one. By all means document functions which do (or are intended to) conform to some standard, and perhaps later remove that mention if the version of the standard in question is obsolete, and newer versions don't include the function in question (or where it is deprecated in them) - but there's no need to include specific text saying that a function is not standard. Simply not saying that it does conform to some standard should be enough. kre
Re: CVS commit: src/lib/libc/stdio
On Tue, May 04, 2010 at 06:35:48PM +0700, Robert Elz wrote: I don't understand the change - that is, I don't understand the sentence that was added to the man page, it says ... The revision marked gets() as obsolete... What revision??? In my manual page: The functions fgets() and gets() conform to ANSI X3.159-1989 (``ANSI C89'') and IEEE Std 1003.1-2001 (``POSIX.1''). The IEEE Std 1003.1-2008 (``POSIX.1'') revision marked gets() as obsolescent, recom- mending the use of fgets() instead. What was the problem again? While I'm here, I would also note that it really makes no sense go racing about documenting things as not complying to some standard or other (by which I mean, that some function is not (or no longer) a standard function, as distinct from our implementation is different from the standard, which is definitely worthy of documentation.) Generally, I disagree. It may be very important to someone to know which functions conform to the stupid standard, possibly to limit something to some dialect only. And in this case it means that gets() probably won't conform to it in the future. You could think about this as a warning. We have LOTS of functions that aren't standardised anywhere, racing around saying they're not, helps no-one. Sure. What is the point? If there is no STANDARDS, there is no standards. Besides, this is false: I haven't done anything like that. By all means document functions which do (or are intended to) conform to some standard, and perhaps later remove that mention if the version of the standard in question is obsolete, and newer versions don't include the function in question (or where it is deprecated in them) - but there's no need to include specific text saying that a function is not standard. Simply not saying that it does conform to some standard should be enough. As something like gets() has been standardized for ages, it makes sense to explicitly note that this may no longer be true (with respect to POSIX). This way a reader (and whoever maintains the page) can also have some sense of history, which is always important in itself. Unlike e.g. ISO, POSIX dares to deprecate stuff, which is a good thing, IMO. In the future, if for instance a function f() is removed from glibc due this, we might want to follow and move f() to some compatibility layer. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Tue, May 04, 2010 at 04:39:16PM +0300, Jukka Ruohonen wrote: In my manual page: The functions fgets() and gets() conform to ANSI X3.159-1989 (``ANSI C89'') and IEEE Std 1003.1-2001 (``POSIX.1''). The IEEE Std 1003.1-2008 (``POSIX.1'') revision marked gets() as obsolescent, recom- mending the use of fgets() instead. What was the problem again? I'd just use In IEEE Std 1003.1-2008 (``POSIX.1'') gets() has been marked as obsolescent. I'd drop the next part as it is already part of the huge CAVEAT. It may be very important to someone to know which functions conform to the stupid standard, possibly to limit something to some dialect only. And in this case it means that gets() probably won't conform to it in the future. You could think about this as a warning. I generally agree. gets(3) is somewhat on the edge as it should never have been used at all, but there are more useful functions that are useful for dealing with ancient systems, but should be avoided for non-compat layers. Joerg
Re: CVS commit: src/lib/libc/stdio
Date:Tue, 4 May 2010 16:39:16 +0300 From:Jukka Ruohonen jruoho...@iki.fi Message-ID: 20100504133916.ga9...@marx.bitnet | In my manual page: [...] | What was the problem again? Something odd - sorry - it looks as if my (older) nroff -mandoc on current sources manages to lose the reference to that standard, though I have no idea why (the same macro works just fine for the earlier references in the paragraph, maybe my macros don't understand the arg). But I see the text you quoted in the source, so that's fine, sorry. | It may be very important to someone to know which functions conform to the | stupid standard, possibly to limit something to some dialect only. I have no problem with that (but note I didn't say stupid standard anywhere...). Documenting what does conform is just fine, it is just what to do with functions that don't (and in this context particularly, functions which once did, but have been removed.) | As something like gets() has been standardized for ages, it makes sense to | explicitly note that this may no longer be true (with respect to POSIX). That's where I disagree, it is just bloat - once it stops being a standardised function, just stop calling it one. If the doc notes that fgets() is POSIX, and says nothing about gets(), the implication is quite clear, isn't it? | This way a reader (and whoever maintains the page) can also have some sense | of history, which is always important in itself. That history will be in the CVS logs. That's enough for maintainers. For others reading the man page, this is all irrelevant (it would almost be better if doc of gets() was deleted completely - the function has to remain, but there's no good reason to tell people they can use it if they're not already doing that.( | Unlike e.g. ISO, POSIX dares to deprecate stuff, which is a good thing, IMO. | In the future, if for instance a function f() is removed from glibc due | this, we might want to follow and move f() to some compatibility layer. I doubt glibc would ever remove anything that important, and I'm very confident that NetBSD never will - recommend against using it, sure - change all NetBSD code to avoid its use, definitely (that's probably already happened), but remove it (from libc, regardless of where else it might be added) - not a chance. That's not just gets(), it is everything (that's documented) which is in libc. kre
Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 12:58:13AM +0700, Robert Elz wrote: | As something like gets() has been standardized for ages, it makes sense to | explicitly note that this may no longer be true (with respect to POSIX). That's where I disagree, it is just bloat - once it stops being a standardised function, just stop calling it one. If the doc notes that fgets() is POSIX, and says nothing about gets(), the implication is quite clear, isn't it? I think the term bloat hardly ever applies to manual pages. If anything, they are often too terse. A paragraph or two about history or standards never hurts anyone. Two additional things: 1. This would make sense if we can be 100 % sure that possible standardization is always mentioned in the manual pages. But based on my experience with the manual pages, this is not true at all. 2. The standards differ. Someone may target SUSv3 but not SUSv4. Just as people still may want to write ANSI C instead of C99 in some settings. That history will be in the CVS logs. That's enough for maintainers. For others reading the man page, this is all irrelevant (it would almost I think the history is relevant or at least interesting; one of the intriguing things about UNIX, really. Often, as a reader, the most interesting thing about a manual page is not the prototype nor the description, but maybe a note about a history (this came from v7 UNIX, who would've guessed?), some small insight or detail, recommended usage scenarios, an example, the caveats, or the references. Standards-jargon is part of all this. be better if doc of gets() was deleted completely - the function has to remain, but there's no good reason to tell people they can use it if they're not already doing that.( As it is documented in gets(3), ANSI C is the only reason for it to exist. Because of this, it probably can never be removed. I doubt glibc would ever remove anything that important, and I'm very confident that NetBSD never will - recommend against using it, sure - change all NetBSD code to avoid its use, definitely (that's probably already happened), but remove it (from libc, regardless of where else it might be added) - not a chance. That's not just gets(), it is everything (that's documented) which is in libc. As Jörg noted, gets() is not really a good example here. A lot of legacy functions were (rightly) marked as obsolete and removed from the IEEE/POSIX standards. I wouldn't put my money on the assumption that Linux maintainers would not ever remove these. And in NetBSD some libc-functions have already been moved to compat -- I would welcome such transitions even more, but that is a different story. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Tue, May 04, 2010 at 07:43:12AM +, Jukka Ruohonen wrote: | Module Name:src | Committed By: jruoho | Date: Tue May 4 07:43:12 UTC 2010 | | Modified Files: | src/lib/libc/stdio: stdio.3 | | Log Message: | Remove the list of functions. | | This list was updated only two times in nearly two decades. | | (If people need to learn the standard I/O functions in C, it would be better | to mention KR or some other textbook; if people need to know the list of | functions, it would be better to point out the location of the standard.) I disagree; a list of all the public APIs for a given library in the main man page for that library is very useful. Please revert this change. cheers, Luke. pgpTyiBtAHkCb.pgp Description: PGP signature
Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 01:03:49PM +1000, Luke Mewburn wrote: On Tue, May 04, 2010 at 07:43:12AM +, Jukka Ruohonen wrote: | Remove the list of functions. | | This list was updated only two times in nearly two decades. | | (If people need to learn the standard I/O functions in C, it would be better | to mention KR or some other textbook; if people need to know the list of | functions, it would be better to point out the location of the standard.) I disagree; a list of all the public APIs for a given library in the main man page for that library is very useful. Please revert this change. I will rever it. With a hope that you or someone else will step up and maintain the page(s). These lists are, in my opinion, something that should not waste the scare documentation resources we have. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Wed, May 05, 2010 at 01:03:49PM +1000, Luke Mewburn wrote: I disagree; a list of all the public APIs for a given library in the main man page for that library is very useful. One more note I have made while skimming through the manual pages. Few examples of pages that are badly and *systematically* behind: intro(3) intro(4) pci(4) usb(4) mk.conf(5) sysctl(7) All of these are a nightmare to maintain. From these, sysctl(7) is probably the only one where I see value in having the list; perhaps mk.conf(5) too, if there would not be bsd.README where everything is duplicated. Otherwise, given the resources we have for documentation, we should try to do our best to avoid clearly more or less unmaintainable documentation, no matter how nice it would be in the ideal case, IMHO. A good example is a listing where things are directly and manually cut-and-pasted from a header file; this is destined to always play a catch-up with the changes in the actual code. - Jukka.
Re: CVS commit: src/lib/libc/stdio
On Sun, Oct 25, 2009 at 05:09:34PM +, David Laight wrote: Lint is differentially far too picky... Remove some warnings that only appear on i386 (not on amd64) and that for some reason best known to others are deemed fatal for i386. Making this code 'pass lint' does absolutely nothing for its readability (etc). we need a new lint. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/stdio
On Mon, Oct 26, 2009 at 06:14:36AM +, David Holland wrote: On Sun, Oct 25, 2009 at 05:09:34PM +, David Laight wrote: Lint is differentially far too picky... Remove some warnings that only appear on i386 (not on amd64) and that for some reason best known to others are deemed fatal for i386. Making this code 'pass lint' does absolutely nothing for its readability (etc). we need a new lint. Is Sun's lint (the one they use for OSnet builds) open source these days? I remember from my days at Sun that it was very good. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libc/stdio
On Sun, Oct 25, 2009 at 05:42:20PM +, Christos Zoulas wrote: Can we just revert the past 2 commits? Changing: (size_t)x - x + 0u does not look like an improvement to me. At least the first shows the intent, the second is just confusing, specially when size_t is unsigned long. Actually, IMHO, lint is just being too picky here. Having to add a cast whenever an 'int' variable is passed to a function that has a 'size_t' parameter really is just polluting the code with pointless casts. I have a deep dislike for casts, and especially ones between integer types. Probably because I've been caught out once too often by an unexpected cast converting beteen pointers and integers. Some of these lint checks really should have been killed once ANSI function prototypes were invernted. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc/stdio
On Oct 26, 2009, at 4:02 PM, David Laight wrote: On Sun, Oct 25, 2009 at 05:42:20PM +, Christos Zoulas wrote: Can we just revert the past 2 commits? Changing: (size_t)x - x + 0u does not look like an improvement to me. At least the first shows the intent, the second is just confusing, specially when size_t is unsigned long. Actually, IMHO, lint is just being too picky here. Having to add a cast whenever an 'int' variable is passed to a function that has a 'size_t' parameter really is just polluting the code with pointless casts. They are different types though. It's a signed vs unsigned issue. James
Re: CVS commit: src/lib/libc/stdio
In article 20091025170934.bd83c17...@cvs.netbsd.org, David Laight source-changes-d@NetBSD.org wrote: -=-=-=-=-=- Module Name: src Committed By: dsl Date: Sun Oct 25 17:09:34 UTC 2009 Modified Files: src/lib/libc/stdio: asprintf.c fgets.c fgetwc.c fread.c fvwrite.c getdelim.c Log Message: Lint is differentially far too picky... Remove some warnings that only appear on i386 (not on amd64) and that for some reason best known to others are deemed fatal for i386. Making this code 'pass lint' does absolutely nothing for its readability (etc). Can we just revert the past 2 commits? Changing: (size_t)x - x + 0u does not look like an improvement to me. At least the first shows the intent, the second is just confusing, specially when size_t is unsigned long. christos
Re: CVS commit: src/lib/libc/stdio
On Thu, Oct 15, 2009 at 12:01:01AM +0200, Alan Barrett wrote:
On Wed, 14 Oct 2009, David Laight wrote:
Module Name:src
Committed By: dsl
Date: Wed Oct 14 21:25:52 UTC 2009
Modified Files:
src/lib/libc/stdio: fgets.c vfprintf.c
Log Message:
Change a while () {} into a do {} while() so that fgets(buf, 1, file)
detects EOF on an empty file.
Fixes most of PR/41992
The changes to vfprintf.c do not seem to match the log message.
Fixed - the preserved local change was all inside #if 0
David
--
David Laight: da...@l8s.co.uk
Re: CVS commit: src/lib/libc/stdio
On Wed, 14 Oct 2009, David Laight wrote:
Module Name: src
Committed By: dsl
Date: Wed Oct 14 21:25:52 UTC 2009
Modified Files:
src/lib/libc/stdio: fgets.c vfprintf.c
Log Message:
Change a while () {} into a do {} while() so that fgets(buf, 1, file)
detects EOF on an empty file.
Fixes most of PR/41992
The changes to vfprintf.c do not seem to match the log message.
--apb (Alan Barrett)
