Subject: lib/21347: "Data" is the plural of "datum."
To: None <gnats-bugs@gnats.netbsd.org>
From: None <kehoea@parhasard.net>
List: netbsd-bugs
Date: 04/28/2003 06:46:07
>Number:         21347
>Category:       lib
>Synopsis:       "Data" is the plural of "datum."
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 28 06:47:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Aidan Kehoe
>Release:        1.6
>Organization:
(not stated)
>Environment:
Not to hand, sorry. 
>Description:
"Data" is the plural of "datum."

This means that, for example, "The data are returned in a buffer allocated
with malloc(3) ..." and "The last parameter is a pointer to any data that need
to get passed to the callback function." would be grammatically correct, and
the forms "The data is returned ..." and "... any data that needs to get
passed..." grammatically incorrect[1]. 

Though not much observed in English today, the idea will be familiar to our
German-speaking and French-speaking friends, where the corresponding terms are
"die Daten" and "les données" respectively. It also still has a certain
academic chic :-) . I'm not going be an idiot and try to convince the whole
world of this, but most of the old man pages observe this rule and it's only
the relatively new ones that don't. Cf, from read(2); 

     [EAGAIN]      The file was marked for non-blocking I/O, and no data were
                   ready to be read.
and setsockopt(2); 

     In the current implementation, this timer is restarted each time
     additional data are delivered to the protocol, implying that the limit
     applies to output portions ranging in size from the low water mark to the
     high water mark for output.

We can at least be consistent in the NetBSD manual. 

The attached patch enforces this for the section three manual pages. I will be
happy to write up similar patches for the other sections, if the principle is
accepted; my source tree is pretty old (1.6P), so I may need to update this
patch too. 

[1] If you have trouble with that, try replacing "data" in the examples with
"datums."

>How-To-Repeat:
(n/a)
>Fix:
--- crypto/dist/heimdal/lib/editline/editline.3~	2000-08-02 20:00:15.000000000 +0000
+++ crypto/dist/heimdal/lib/editline/editline.3	2003-04-27 18:24:13.000000000 +0000
@@ -23,8 +23,8 @@
 The
 .I readline
 routine returns a line of text with the trailing newline removed.
-The data is returned in a buffer allocated with
+The data are returned in a buffer allocated with
 .IR malloc (3),
 so the space should be released with
 .IR free (3)
--- crypto/dist/krb4/lib/editline/editline.3~	2000-12-29 01:43:48.000000000 +0000
+++ crypto/dist/krb4/lib/editline/editline.3	2003-04-27 17:23:18.000000000 +0000
@@ -23,7 +23,7 @@
 The
 .I readline
 routine returns a line of text with the trailing newline removed.
-The data is returned in a buffer allocated with
+The data are returned in a buffer allocated with
 .IR malloc (3),
 so the space should be released with
 .IR free (3)
--- crypto/dist/krb4/lib/krb/krb_sendauth.3~	2002-09-12 12:22:09.000000000 +0000
+++ crypto/dist/krb4/lib/krb/krb_sendauth.3	2003-04-27 17:24:56.000000000 +0000
@@ -316,8 +316,8 @@
 .I krb_net_write
 function
 emulates the write(2) system call, but guarantees that all data
-specified is written to
+specified are written to
 .I fd
 before returning, unless an error condition occurs.
 .PP
--- dist/cdk/man/cdk_alphalist.3~	2001-08-20 12:20:01.000000000 +0000
+++ dist/cdk/man/cdk_alphalist.3	2003-04-27 18:16:06.000000000 +0000
@@ -406,7 +406,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 call-back function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the call-back function.
 .RE
 
--- dist/cdk/man/cdk_buttonbox.3~	2001-08-20 12:20:01.000000000 +0000
+++ dist/cdk/man/cdk_buttonbox.3	2003-04-27 18:16:41.000000000 +0000
@@ -353,7 +353,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f2cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_calendar.3~	2001-08-20 12:20:01.000000000 +0000
+++ dist/cdk/man/cdk_calendar.3	2003-04-27 18:17:13.000000000 +0000
@@ -386,7 +386,7 @@
 pointer to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to
+parameter \f2data\f1 is a pointer to any data that need to get passed to
 the callback function.
 .RE
 
--- dist/cdk/man/cdk_dialog.3~	2003-01-04 00:37:17.000000000 +0000
+++ dist/cdk/man/cdk_dialog.3	2003-04-27 18:17:37.000000000 +0000
@@ -369,7 +369,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f2cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_entry.3~	2003-01-04 00:37:17.000000000 +0000
+++ dist/cdk/man/cdk_entry.3	2003-04-27 17:26:43.000000000 +0000
@@ -499,7 +499,7 @@
 widget object. The \f2key\f1 is the character to bind. The \f2function\f1 is 
 the function type. To learn more about the key binding callback function types
 read the \f4cdk_binding\f1 manual page. The last parameter \f2data\f1 is a 
-pointer to any data that needs to get passed to the callback function.
+pointer to any data that need to get passed to the callback function.
 .RE
 
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_fselect.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_fselect.3	2003-04-27 17:27:01.000000000 +0000
@@ -450,7 +450,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 call-back function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the call-back function.
 .RE
 
--- dist/cdk/man/cdk_itemlist.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_itemlist.3	2003-04-27 17:29:31.000000000 +0000
@@ -381,7 +381,7 @@
 the widget object. The \f2key\f1 is the character to bind. The \f2function\f1 
 is the function type. To learn more about the key binding callback function 
 types read the \f4cdk_binding\f1 manual page. The last parameter \f2data\f1 
-is a pointer to any data that needs to get passed to the callback function.
+is a pointer to any data that need to get passed to the callback function.
 .RE
 
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_matrix.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_matrix.3	2003-04-27 17:29:52.000000000 +0000
@@ -454,7 +454,7 @@
 the widget object. The \f2key\f1 is the character to bind. The \f2function\f1 
 is the function type. To learn more about the key binding callback function 
 types read the \f4cdk_binding\f1 manual page. The last parameter \f2data\f1 
-is a pointer to any data that needs to get passed to the callback function.
+is a pointer to any data that need to get passed to the callback function.
 .RE
 
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_mentry.3~	2003-01-04 00:37:17.000000000 +0000
+++ dist/cdk/man/cdk_mentry.3	2003-04-27 17:30:13.000000000 +0000
@@ -466,7 +466,7 @@
 pointer to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to
+parameter \f2data\f1 is a pointer to any data that need to get passed to
 the callback function.
 .RE
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_menu.3~	2001-01-04 19:59:09.000000000 +0000
+++ dist/cdk/man/cdk_menu.3	2003-04-27 17:30:34.000000000 +0000
@@ -215,7 +215,7 @@
 pointer to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 
--- dist/cdk/man/cdk_radio.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_radio.3	2003-04-27 17:30:55.000000000 +0000
@@ -413,7 +413,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 
--- dist/cdk/man/cdk_scale.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_scale.3	2003-04-27 17:31:16.000000000 +0000
@@ -384,7 +384,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 
--- dist/cdk/man/cdk_scroll.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_scroll.3	2003-04-27 17:31:32.000000000 +0000
@@ -406,7 +406,7 @@
 the widget object. The \f2key\f1 is the character to bind. The \f2function\f1 
 is the function type. To learn more about the key binding callback function 
 types read the \f4cdk_binding\f1 manual page. The last parameter \f2data\f1 
-is a pointer to any data that needs to get passed to the callback function.
+is a pointer to any data that need to get passed to the callback function.
 .RE
 .SH KEY BINDINGS
 When the widget is activated there are several default key bindings which will
--- dist/cdk/man/cdk_selection.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_selection.3	2003-04-27 17:31:39.000000000 +0000
@@ -400,7 +400,7 @@
 pointer to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 
--- dist/cdk/man/cdk_slider.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_slider.3	2003-04-27 17:31:55.000000000 +0000
@@ -380,7 +380,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 
--- dist/cdk/man/cdk_swindow.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_swindow.3	2003-04-27 17:32:02.000000000 +0000
@@ -432,7 +432,7 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 callback function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the callback function.
 .RE
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_template.3~	2001-08-20 12:20:02.000000000 +0000
+++ dist/cdk/man/cdk_template.3	2003-04-27 17:32:10.000000000 +0000
@@ -427,7 +427,7 @@
 the widget object. The \f2key\f1 is the character to bind. The \f2function\f1 
 is the function type. To learn more about the key binding callback function 
 types read the \f4cdk_binding\f1 manual page. The last parameter \f2data\f1 
-is a pointer to any data that needs to get passed to the callback function.
+is a pointer to any data that need to get passed to the callback function.
 .RE
 
 .SH KEY BINDINGS
--- dist/cdk/man/cdk_viewer.3~	2001-08-20 12:20:03.000000000 +0000
+++ dist/cdk/man/cdk_viewer.3	2003-04-27 17:32:17.000000000 +0000
@@ -365,8 +365,8 @@
 to the widget object. The \f2key\f1 is the character to bind. The 
 \f2function\f1 is the function type. To learn more about the key binding 
 call-back function types read the \f4cdk_binding\f1 manual page. The last 
-parameter \f2data\f1 is a pointer to any data that needs to get passed to 
+parameter \f2data\f1 is a pointer to any data that need to get passed to 
 the call-back function.
 .RE
 .SH KEY BINDINGS
--- lib/libc/gen/getfsent.3~	2002-02-07 07:00:12.000000000 +0000
+++ lib/libc/gen/getfsent.3	2003-04-27 17:36:33.000000000 +0000
@@ -148,5 +148,5 @@
 .Bx 4.3 .
 .Sh BUGS
 These functions use static data storage;
-if the data is needed for future use, it should be
-copied before any subsequent calls overwrite it.
+if the data are needed for future use, they should be
+copied before any subsequent calls overwrite them.
--- lib/libc/gen/getttyent.3~	2002-10-01 16:48:34.000000000 +0000
+++ lib/libc/gen/getttyent.3	2003-04-27 17:36:55.000000000 +0000
@@ -202,5 +202,5 @@
 .Bx 4.3 .
 .Sh BUGS
 These functions use static data storage;
-if the data is needed for future use, it should be
-copied before any subsequent calls overwrite it.
+if the data are needed for future use, they should be
+copied before any subsequent calls overwrite them.
--- lib/libc/gen/nlist.3~	2002-10-01 16:48:35.000000000 +0000
+++ lib/libc/gen/nlist.3	2003-04-27 17:37:08.000000000 +0000
@@ -66,7 +66,7 @@
 for the entry are copied into the list
 referenced by
 .Fa \&nl .
-No other data is copied.
+No other data are copied.
 The last entry in the list is always
 .Dv NULL .
 .Sh RETURN VALUES
--- lib/libc/gen/sysctl.3~	2003-03-06 20:39:08.000000000 +0000
+++ lib/libc/gen/sysctl.3	2003-04-27 17:37:22.000000000 +0000
@@ -770,7 +770,7 @@
 .Bl -tag -width "123456"
 .It Li PF_ROUTE
 Return the entire routing table or a subset of it.
-The data is returned as a sequence of routing messages (see
+The data are returned as a sequence of routing messages (see
 .Xr route 4
 for the header file, format and meaning).
 The length of each message is contained in the message header.
--- lib/libc/net/gethostbyname.3~	2002-10-02 10:48:35.000000000 +0000
+++ lib/libc/net/gethostbyname.3	2003-04-27 17:37:39.000000000 +0000
@@ -293,7 +293,7 @@
 IPv6 support was implemented in WIDE Hydrangea IPv6 protocol stack kit.
 .Sh BUGS
 These functions use static data storage;
-if the data is needed for future use, it should be
-copied before any subsequent calls overwrite it.
+if the data are needed for future use, they should be
+copied before any subsequent calls overwrite them.
 Only the Internet
 address format is currently understood.
--- lib/libc/net/getprotoent.3~	2002-02-07 07:00:20.000000000 +0000
+++ lib/libc/net/getprotoent.3	2003-04-27 17:37:55.000000000 +0000
@@ -142,7 +142,7 @@
 .Bx 4.2 .
 .Sh BUGS
 These functions use a static data space;
-if the data is needed for future use, it should be
-copied before any subsequent calls overwrite it.
+if the data are needed for future use, they should be
+copied before any subsequent calls overwrite them.
 Only the Internet
 protocols are currently understood.
--- lib/libc/net/getservent.3~	2002-02-07 07:00:20.000000000 +0000
+++ lib/libc/net/getservent.3	2003-04-27 17:38:26.000000000 +0000
@@ -152,7 +152,7 @@
 .Bx 4.2 .
 .Sh BUGS
 These functions use static data storage;
-if the data is needed for future use, it should be
-copied before any subsequent calls overwrite it.
+if the data are needed for future use, they should be
+copied before any subsequent calls overwrite them. 
 Expecting port numbers to fit in a 32 bit
 quantity is probably naive.
--- lib/libc/rpc/xdr.3~	2003-01-18 11:29:07.000000000 +0000
+++ lib/libc/rpc/xdr.3	2003-04-27 17:39:14.000000000 +0000
@@ -374,7 +374,7 @@
 .SM XDR
 stream object pointed to by
 .IR xdrs .
-The stream's data is written to, or read from,
+The stream's data are written to, or read from,
 a chunk of memory at location
 .I addr
 whose length is no more than
@@ -457,11 +457,11 @@
 .SM XDR
 stream object pointed to by
 .IR xdrs .
-The stream's data is written to a buffer of size
+The stream's data are written to a buffer of size
 .IR sendsize ;
 a value of zero indicates the system should use a suitable
 default.
-The stream's data is read from a buffer of size
+The stream's data are read from a buffer of size
 .IR recvsize ;
 it too can be set to a suitable default by passing a zero
 value.
@@ -649,7 +649,7 @@
 .IR xdrs .
 The
 .SM XDR
-stream data is written to, or read from, the Standard
+stream data are written to, or read from, the Standard
 .B I/O
 stream
 .IR file .
--- lib/libc/stdio/fclose.3~	2003-01-18 11:29:50.000000000 +0000
+++ lib/libc/stdio/fclose.3	2003-04-27 17:39:25.000000000 +0000
@@ -56,7 +56,7 @@
 dissociates the named
 .Fa stream
 from its underlying file or set of functions.
-If the stream was being used for output, any buffered data is written
+If the stream was being used for output, any buffered data are written
 first, using
 .Xr fflush 3 .
 .Sh RETURN VALUES
--- lib/libc/time/ctime.3~	2002-10-01 18:15:59.000000000 +0000
+++ lib/libc/time/ctime.3	2003-04-27 17:39:44.000000000 +0000
@@ -237,7 +237,7 @@
 functions conform to
 .St -p1003.1c-95 .
 .Sh NOTES
-The return values point to static data; the data is overwritten by
+The return values point to static data; the data are overwritten by
 each call.
 The
 .Fa tm_zone
--- lib/libcrypto/man/BIO_f_base64.3~	2002-08-09 16:15:36.000000000 +0000
+++ lib/libcrypto/man/BIO_f_base64.3	2003-04-27 17:40:59.000000000 +0000
@@ -164,7 +164,7 @@
 Base64 BIOs do not support \fIBIO_gets()\fR or \fIBIO_puts()\fR. 
 .PP
 \&\fIBIO_flush()\fR on a base64 \s-1BIO\s0 that is being written through is
-used to signal that no more data is to be encoded: this is used
+used to signal that no more data are to be encoded: this is used
 to flush the final block through the \s-1BIO\s0.
 .PP
 The flag \s-1BIO_FLAGS_BASE64_NO_NL\s0 can be set with \fIBIO_set_flags()\fR
--- lib/libcrypto/man/BIO_f_buffer.3~	2002-08-09 16:15:36.000000000 +0000
+++ lib/libcrypto/man/BIO_f_buffer.3	2003-04-27 17:41:26.000000000 +0000
@@ -177,7 +177,7 @@
 \&\fIBIO_set_read_buffer_size()\fR, \fIBIO_set_write_buffer_size()\fR and \fIBIO_set_buffer_size()\fR
 set the read, write or both read and write buffer sizes to \fBsize\fR. The initial
 buffer size is \s-1DEFAULT_BUFFER_SIZE\s0, currently 1024. Any attempt to reduce the
-buffer size below \s-1DEFAULT_BUFFER_SIZE\s0 is ignored. Any buffered data is cleared
+buffer size below \s-1DEFAULT_BUFFER_SIZE\s0 is ignored. Any buffered data are cleared
 when the buffer is resized.
 .PP
 \&\fIBIO_set_buffer_read_data()\fR clears the read buffer and fills it with \fBnum\fR
@@ -190,7 +190,7 @@
 possible to provide \fIBIO_gets()\fR functionality if the following BIOs do not
 support it (for example \s-1SSL\s0 BIOs).
 .PP
-Data is only written to the next \s-1BIO\s0 in the chain when the write buffer fills
+Data are only written to the next \s-1BIO\s0 in the chain when the write buffer fills
 or when \fIBIO_flush()\fR is called. It is therefore important to call \fIBIO_flush()\fR
 whenever any pending data should be written such as when removing a buffering
 \&\s-1BIO\s0 using \fIBIO_pop()\fR. \fIBIO_flush()\fR may need to be retried if the ultimate
--- lib/libcrypto/man/BIO_f_cipher.3~	2002-08-09 16:15:36.000000000 +0000
+++ lib/libcrypto/man/BIO_f_cipher.3	2003-04-27 17:41:37.000000000 +0000
@@ -169,7 +169,7 @@
 Cipher BIOs do not support \fIBIO_gets()\fR or \fIBIO_puts()\fR. 
 .PP
 \&\fIBIO_flush()\fR on an encryption \s-1BIO\s0 that is being written through is
-used to signal that no more data is to be encrypted: this is used
+used to signal that no more data are to be encrypted: this is used
 to flush and possibly pad the final block through the \s-1BIO\s0.
 .PP
 \&\fIBIO_set_cipher()\fR sets the cipher of \s-1BIO\s0 <b> to \fBcipher\fR using key \fBkey\fR
--- lib/libcrypto/man/BIO_f_md.3~	2002-08-09 16:15:36.000000000 +0000
+++ lib/libcrypto/man/BIO_f_md.3	2003-04-27 17:41:54.000000000 +0000
@@ -175,7 +175,7 @@
 \&\fIBIO_reset()\fR reinitializes a digest \s-1BIO\s0.
 .PP
 \&\fIBIO_set_md()\fR sets the message digest of \s-1BIO\s0 \fBb\fR to \fBmd\fR: this
-must be called to initialize a digest \s-1BIO\s0 before any data is
+must be called to initialize a digest \s-1BIO\s0 before any data are
 passed through it. It is a \fIBIO_ctrl()\fR macro.
 .PP
 \&\fIBIO_get_md()\fR places the a pointer to the digest BIOs digest method
@@ -195,7 +195,7 @@
 .PP
 After the digest has been retrieved from a digest \s-1BIO\s0 it must be
 reinitialized by calling \fIBIO_reset()\fR, or \fIBIO_set_md()\fR before any more
-data is passed through it.
+data are passed through it.
 .PP
 If an application needs to call \fIBIO_gets()\fR or \fIBIO_puts()\fR through
 a chain containing digest BIOs then this can be done by prepending
--- lib/libcrypto/man/BIO_new_bio_pair.3~	2002-08-09 16:15:37.000000000 +0000
+++ lib/libcrypto/man/BIO_new_bio_pair.3	2003-04-27 17:42:11.000000000 +0000
@@ -208,13 +208,13 @@
 buffer is full or the read buffer is drained. Then the application has to
 flush the write buffer and/or fill the read buffer.
 .PP
-Use the \fIBIO_ctrl_pending()\fR, to find out whether data is buffered in the \s-1BIO\s0
+Use the \fIBIO_ctrl_pending()\fR, to find out whether data are buffered in the \s-1BIO\s0
 and must be transfered to the network. Use \fIBIO_ctrl_get_read_request()\fR to
 find out, how many bytes must be written into the buffer before the
 \&\fISSL_operation()\fR can successfully be continued.
 .SH "IMPORTANT"
 .IX Header "IMPORTANT"
-As the data is buffered, \fISSL_operation()\fR may return with a \s-1ERROR_SSL_WANT_READ\s0
+As the data are buffered, \fISSL_operation()\fR may return with a \s-1ERROR_SSL_WANT_READ\s0
 condition, but there is still data in the write buffer. An application must
 not rely on the error value of \fISSL_operation()\fR but must assure that the
 write buffer is always flushed first. Otherwise a deadlock may occur as
--- lib/libcrypto/man/BIO_push.3~	2002-08-09 16:15:37.000000000 +0000
+++ lib/libcrypto/man/BIO_push.3	2003-04-27 17:42:31.000000000 +0000
@@ -192,9 +192,9 @@
 the new chain is \fBmd1\-md2\-b64\-f\fR. Data written to \fBmd1\fR will be digested
 by \fBmd1\fR and \fBmd2\fR, \fBbase64\fR encoded and written to \fBf\fR.
 .PP
-It should be noted that reading causes data to pass in the reverse
-direction, that is data is read from \fBf\fR, base64 \fBdecoded\fR and digested
-by \fBmd1\fR and \fBmd2\fR. If the call:
+It should be noted that reading causes data to pass in the reverse direction,
+that is data are read from \fBf\fR, base64 \fBdecoded\fR and digested by
+\fBmd1\fR and \fBmd2\fR. If the call:
 .PP
 .Vb 1
 \& BIO_pop(md2);
--- lib/libcrypto/man/BIO_read.3~	2002-08-09 16:15:37.000000000 +0000
+++ lib/libcrypto/man/BIO_read.3	2003-04-27 17:42:54.000000000 +0000
@@ -181,18 +181,18 @@
 .IX Header "NOTES"
 A 0 or \-1 return is not necessarily an indication of an error. In
 particular when the source/sink is non-blocking or of a certain type
-it may merely be an indication that no data is currently available and that
+it may merely be an indication that no data are currently available and that
 the application should retry the operation later.
 .PP
 One technique sometimes used with blocking sockets is to use a system call
-(such as \fIselect()\fR, \fIpoll()\fR or equivalent) to determine when data is available
-and then call \fIread()\fR to read the data. The equivalent with BIOs (that is call
-\&\fIselect()\fR on the underlying I/O structure and then call \fIBIO_read()\fR to
-read the data) should \fBnot\fR be used because a single call to \fIBIO_read()\fR
-can cause several reads (and writes in the case of \s-1SSL\s0 BIOs) on the underlying
-I/O structure and may block as a result. Instead \fIselect()\fR (or equivalent)
-should be combined with non blocking I/O so successive reads will request
-a retry instead of blocking.
+(such as \fIselect()\fR, \fIpoll()\fR or equivalent) to determine when data
+are available and then call \fIread()\fR to read the data. The equivalent with
+BIOs (that is call \&\fIselect()\fR on the underlying I/O structure and then
+call \fIBIO_read()\fR to read the data) should \fBnot\fR be used because a
+single call to \fIBIO_read()\fR can cause several reads (and writes in the
+case of \s-1SSL\s0 BIOs) on the underlying I/O structure and may block as a
+result. Instead \fIselect()\fR (or equivalent) should be combined with non
+blocking I/O so successive reads will request a retry instead of blocking.
 .PP
 See BIO_should_retry(3) for details of how to
 determine the cause of a retry and other I/O issues.
--- lib/libcrypto/man/BIO_s_bio.3~	2002-08-09 16:15:37.000000000 +0000
+++ lib/libcrypto/man/BIO_s_bio.3	2003-04-27 17:43:14.000000000 +0000
@@ -198,7 +198,7 @@
 \&\s-1TLS/SSL\s0 or the normal socket routines are inappropriate.
 .PP
 Calls to \fIBIO_read()\fR will read data from the buffer or request a retry if no
-data is available.
+data are available.
 .PP
 Calls to \fIBIO_write()\fR will place data in the buffer or request a retry if the
 buffer is full.
--- lib/libcrypto/man/BIO_s_mem.3~	2002-08-09 16:15:37.000000000 +0000
+++ lib/libcrypto/man/BIO_s_mem.3	2003-04-27 17:43:39.000000000 +0000
@@ -185,7 +185,7 @@
 read only \s-1BIO\s0 it restores the \s-1BIO\s0 to its original state and the read only
 data can be read again.
 .PP
-\&\fIBIO_eof()\fR is true if no data is in the \s-1BIO\s0.
+\&\fIBIO_eof()\fR is true if no data are in the \s-1BIO\s0.
 .PP
 \&\fIBIO_ctrl_pending()\fR returns the number of bytes currently stored.
 .PP
@@ -211,7 +211,7 @@
 length is determined by \fBstrlen\fR. The \s-1BIO\s0 is set to a read only state and
 as a result cannot be written to. This is useful when some data needs to be
 made available from a static area of memory in the form of a \s-1BIO\s0. The
-supplied data is read directly from the supplied buffer: it is \fBnot\fR copied
+supplied data are read directly from the supplied buffer: it is \fBnot\fR copied
 first, so the supplied area of memory must be unchanged until the \s-1BIO\s0 is freed.
 .SH "NOTES"
 .IX Header "NOTES"
--- lib/libcrypto/man/BIO_should_retry.3~	2002-08-09 16:15:37.000000000 +0000
+++ lib/libcrypto/man/BIO_should_retry.3	2003-04-27 17:44:58.000000000 +0000
@@ -229,12 +229,12 @@
 .PP
 While an application may retry a failed non blocking call immediately
 this is likely to be very inefficient because the call will fail
-repeatedly until data can be processed or is available. An application
+repeatedly until data can be processed or are available. An application
 will normally wait until the necessary condition is satisfied. How
 this is done depends on the underlying I/O structure.
 .PP
 For example if the cause is ultimately a socket and \fIBIO_should_read()\fR
-is true then a call to \fIselect()\fR may be made to wait until data is
+is true then a call to \fIselect()\fR may be made to wait until data are
 available and then retry the \s-1BIO\s0 operation. By combining the retry
 conditions of several non blocking BIOs in a single \fIselect()\fR call
 it is possible to service several BIOs in a single thread, though
--- lib/libcrypto/man/CRYPTO_set_ex_data.3~	2002-08-09 16:15:38.000000000 +0000
+++ lib/libcrypto/man/CRYPTO_set_ex_data.3	2003-04-27 17:47:51.000000000 +0000
@@ -164,12 +164,12 @@
 \&\fB\s-1CRYPTO_EX_DATA\s0\fR structures passed to the \fB\f(BInew_func()\fB\fR, \fB\f(BIfree_func()\fB\fR and
 \&\fB\f(BIdup_func()\fB\fR callbacks: as passed to \fB\f(BIRSA_get_ex_new_index()\fB\fR for example.
 .PP
-\&\fB\f(BICRYPTO_set_ex_data()\fB\fR is used to set application specific data, the data is
-supplied in the \fBarg\fR parameter and its precise meaning is up to the
+\&\fB\f(BICRYPTO_set_ex_data()\fB\fR is used to set application specific data, the data are
+supplied in the \fBarg\fR parameter and their precise meaning is up to the
 application.
 .PP
 \&\fB\f(BICRYPTO_get_ex_data()\fB\fR is used to retrieve application specific data. The data
-is returned to the application, this will be the same value as supplied to
+are returned to the application, and will be the same data supplied to
 a previous \fB\f(BICRYPTO_set_ex_data()\fB\fR call.
 .SH "RETURN VALUES"
 .IX Header "RETURN VALUES"
--- lib/libcrypto/man/EVP_EncryptInit.3~	2002-08-09 16:15:39.000000000 +0000
+++ lib/libcrypto/man/EVP_EncryptInit.3	2003-04-27 17:48:27.000000000 +0000
@@ -244,7 +244,7 @@
 .PP
 \&\fIEVP_EncryptFinal()\fR encrypts the \*(L"final\*(R" data, that is any data that
 remains in a partial block. It uses standard block padding (aka \s-1PKCS\s0
-padding). The encrypted final data is written to \fBout\fR which should
+padding). The encrypted final data are written to \fBout\fR which should
 have sufficient space for one cipher block. The number of bytes written
 is placed in \fBoutl\fR. After this function is called the encryption operation
 is finished and no further calls to \fIEVP_EncryptUpdate()\fR should be made.
@@ -424,11 +424,11 @@
 preference to the low level interfaces. This is because the code then becomes
 transparent to the cipher used and much more flexible.
 .PP
-\&\s-1PKCS\s0 padding works by adding \fBn\fR padding bytes of value \fBn\fR to make the total 
-length of the encrypted data a multiple of the block size. Padding is always
-added so if the data is already a multiple of the block size \fBn\fR will equal
-the block size. For example if the block size is 8 and 11 bytes are to be
-encrypted then 5 padding bytes of value 5 will be added.
+\&\s-1PKCS\s0 padding works by adding \fBn\fR padding bytes of value \fBn\fR
+to make the total length of the encrypted data a multiple of the block size.
+Padding is always added so if the data are already a multiple of the block
+size \fBn\fR will equal the block size. For example if the block size is 8 and
+11 bytes are to be encrypted then 5 padding bytes of value 5 will be added.
 .PP
 When decrypting the final block is checked to see if it has the correct form.
 .PP
--- lib/libcrypto/man/RSA_get_ex_new_index.3~	2002-08-09 16:15:39.000000000 +0000
+++ lib/libcrypto/man/RSA_get_ex_new_index.3	2003-04-27 17:49:15.000000000 +0000
@@ -195,8 +195,8 @@
 will return an index greater than any previously returned, this is important
 because the optional functions are called in order of increasing index value.
 .PP
-\&\fB\f(BIRSA_set_ex_data()\fB\fR is used to set application specific data, the data is
-supplied in the \fBarg\fR parameter and its precise meaning is up to the
+\&\fB\f(BIRSA_set_ex_data()\fB\fR is used to set application specific data, the data are
+supplied in the \fBarg\fR parameter and their precise meaning is up to the
 application.
 .PP
 \&\fB\f(BIRSA_get_ex_data()\fB\fR is used to retrieve application specific data. The data
--- lib/libcrypto/man/SSL_SESSION_get_ex_new_index.3~	2002-08-09 16:15:42.000000000 +0000
+++ lib/libcrypto/man/SSL_SESSION_get_ex_new_index.3	2003-04-27 17:49:44.000000000 +0000
@@ -192,8 +192,8 @@
 CRYPTO_set_ex_data(3).
 .SH "WARNINGS"
 .IX Header "WARNINGS"
-The application data is only maintained for sessions held in memory. The
-application data is not included when dumping the session with
+The application data are only maintained for sessions held in memory. The
+application data are not included when dumping the session with
 \&\fIi2d_SSL_SESSION()\fR (and all functions indirectly calling the dump functions
 like \fIPEM_write_SSL_SESSION()\fR and \fIPEM_write_bio_SSL_SESSION()\fR) and can
 therefore not be restored.
--- lib/libcrypto/man/SSL_get_session.3~	2002-08-09 16:15:43.000000000 +0000
+++ lib/libcrypto/man/SSL_get_session.3	2003-04-27 17:50:09.000000000 +0000
@@ -179,7 +179,7 @@
 if the session is valid, it can be removed at any time due to timeout
 during SSL_CTX_flush_sessions(3).
 .PP
-If the data is to be kept, \fISSL_get1_session()\fR will increment the reference
+If the data are to be kept, \fISSL_get1_session()\fR will increment the reference
 count, so that the session will not be implicitly removed by other operations
 but stays in memory. In order to remove the session
 SSL_SESSION_free(3) must be explicitly called once
--- lib/libcrypto/man/openssl_buffer.3~	2002-08-09 16:15:44.000000000 +0000
+++ lib/libcrypto/man/openssl_buffer.3	2003-04-27 17:51:28.000000000 +0000
@@ -185,11 +185,11 @@
 .PP
 \&\fIBUF_MEM_new()\fR allocates a new buffer of zero size.
 .PP
-\&\fIBUF_MEM_free()\fR frees up an already existing buffer. The data is zeroed
+\&\fIBUF_MEM_free()\fR frees up an already existing buffer. The data are zeroed
 before freeing up in case the buffer contains sensitive data.
 .PP
 \&\fIBUF_MEM_grow()\fR changes the size of an already existing buffer to
-\&\fBlen\fR. Any data already in the buffer is preserved if it increases in
+\&\fBlen\fR. Any data already in the buffer are preserved if it increases in
 size.
 .PP
 \&\fIBUF_strdup()\fR copies a null terminated string into a block of allocated
--- lib/libcrypto/man/openssl_des.3~	2002-08-09 16:15:45.000000000 +0000
+++ lib/libcrypto/man/openssl_des.3	2003-04-27 17:53:33.000000000 +0000
@@ -438,16 +438,16 @@
 of \fIcrypt\fR\|(3).
 .PP
 \&\fIdes_enc_write()\fR writes \fIlen\fR bytes to file descriptor \fIfd\fR from
-buffer \fIbuf\fR. The data is encrypted via \fIpcbc_encrypt\fR (default)
+buffer \fIbuf\fR. The data are encrypted via \fIpcbc_encrypt\fR (default)
 using \fIsched\fR for the key and \fIiv\fR as a starting vector.  The actual
-data send down \fIfd\fR consists of 4 bytes (in network byte order)
+data sent down \fIfd\fR consist of 4 bytes (in network byte order)
 containing the length of the following encrypted data.  The encrypted
-data then follows, padded with random data out to a multiple of 8
+data then follow, padded with random data out to a multiple of 8
 bytes.
 .PP
 \&\fIdes_enc_read()\fR is used to read \fIlen\fR bytes from file descriptor
-\&\fIfd\fR into buffer \fIbuf\fR. The data being read from \fIfd\fR is assumed to
-have come from \fIdes_enc_write()\fR and is decrypted using \fIsched\fR for
+\&\fIfd\fR into buffer \fIbuf\fR. The data being read from \fIfd\fR are assumed to
+have come from \fIdes_enc_write()\fR and are decrypted using \fIsched\fR for
 the key schedule and \fIiv\fR for the initial vector.
 .PP
 \&\fBWarning:\fR The data format used by \fIdes_enc_write()\fR and \fIdes_enc_read()\fR
--- lib/libcrypto/man/openssl_rand.3~	2002-08-09 16:15:46.000000000 +0000
+++ lib/libcrypto/man/openssl_rand.3	2003-04-27 17:56:46.000000000 +0000
@@ -227,7 +227,7 @@
 When using data to seed the \s-1RNG\s0 state, the data used should not be
 extractable from the \s-1RNG\s0 state.  I believe this should be a
 requirement because one possible source of 'secret' semi random
-data would be a private key or a password.  This data must
+data would be a private key or a password.  These data must
 not be disclosed by either subsequent random numbers or a
 \&'core' dump left by a program crash.
 .Ip "6" 4
@@ -244,13 +244,13 @@
 There is global state made up of a 1023 byte buffer (the 'state'), a
 working hash value ('md'), and a counter ('count').
 .PP
-Whenever seed data is added, it is inserted into the 'state' as
+Whenever seed data are added, they are inserted into the 'state' as
 follows.
 .PP
 The input is chopped up into units of 20 bytes (or less for
 the last block).  Each of these blocks is run through the hash
 function as follows:  The data passed to the hash function
-is the current 'md', the same number of bytes from the 'state'
+are the current 'md', the same number of bytes from the 'state'
 (the location determined by in incremented looping index) as
 the current 'block', the new key data 'block', and 'count'
 (which is incremented after each use).
@@ -276,7 +276,7 @@
 into the hash function and the results are kept in the global 'md'.
 .PP
 I believe the above addressed points 1 (use of \s-1SHA-1\s0), 6 (by hashing
-into the 'state' the 'old' data from the caller that is about to be
+into the 'state' the 'old' data from the caller that are about to be
 overwritten) and 7 (by not using the 10 bytes given to the caller to
 update the 'state', but they are used to update 'md').
 .PP
--- lib/libcurses/curses_scanw.3~	2003-02-14 16:29:12.000000000 +0000
+++ lib/libcurses/curses_scanw.3	2003-04-27 17:57:20.000000000 +0000
@@ -86,7 +86,7 @@
 is called to move the cursor to the position specified by
 .Fa y ,
 .Fa x
-before the data is read from the window.
+before the data are read from the window.
 .Sh RETURN VALUES
 Functions returning pointers will return
 .Dv NULL
--- lib/libform/form_data.3~	2002-10-01 19:15:15.000000000 +0000
+++ lib/libform/form_data.3	2003-04-27 17:58:06.000000000 +0000
@@ -44,17 +44,17 @@
 .Ft int
 .Fn data_behind "FORM *form"
 .Sh DESCRIPTION
-If there is data offscreen to the right of the current field of the
+If there are data offscreen to the right of the current field of the
 given form then
 .Fn data_ahead
 will return TRUE, otherwise FALSE is returned.
-Similarly, if there is
+Similarly, if there are
 data offscreen to the left of the current field of the given form then
 .Fn data_behind
 will return TRUE.
 .Sh RETURN VALUES
 If the condition is met then the functions will return TRUE, if there
-is an error or there is no data offscreen the functions will return
+is an error or there are no data offscreen the functions will return
 FALSE.
 .Sh SEE ALSO
 .Xr curses 3 ,
--- lib/libform/forms.3~	2002-10-01 19:15:17.000000000 +0000
+++ lib/libform/forms.3	2003-04-27 17:58:28.000000000 +0000
@@ -196,7 +196,7 @@
 .Pp
 .Bl -tag -width "circular fields" -compact
 .It field wrapping
-For multiline fields the data will be wrapped as it is entered, this
+For multiline fields the data will be wrapped as they are entered, this
 does not happen in the AT\*[Am]T implementation.
 .It buffer 0
 In this implementation, the contents of buffer 0 are always current
--- lib/libkvm/kvm_dump.3~	2002-10-01 19:18:13.000000000 +0000
+++ lib/libkvm/kvm_dump.3	2003-04-27 17:58:53.000000000 +0000
@@ -73,7 +73,7 @@
 .Fn kvm_dump_wrtheader .
 This function takes care of generating the generic header, the CORE_CPU
 section and the section header of the CORE_DATA section.
-The data is written to the file pointed at by
+The data are written to the file pointed at by
 .Fa fp .
 The
 .Fa dumpsize
--- lib/libkvm/kvm_getprocs.3~	2002-10-02 10:59:45.000000000 +0000
+++ lib/libkvm/kvm_getprocs.3	2003-04-27 17:59:07.000000000 +0000
@@ -175,7 +175,7 @@
 function is similar to
 .Fn kvm_getargv
 but returns the vector of environment strings.
-This data is also alterable by the process.
+These data are also alterable by the process.
 .Pp
 .Fn kvm_getproc2
 is similar to
--- lib/libusbhid/usbhid.3~	2003-02-14 16:29:12.000000000 +0000
+++ lib/libusbhid/usbhid.3	2003-04-27 18:00:17.000000000 +0000
@@ -101,7 +101,7 @@
 Alternatively a data buffer containing the report descriptor can be
 passed into
 .Fn hid_use_report_desc .
-The data is copied into an internal structure.
+The data are copied into an internal structure.
 When the report descriptor
 is no longer needed it should be freed by calling
 .Fn hid_dispose_report_desc .

>Release-Note:
>Audit-Trail:
>Unformatted: