Your message dated Wed, 26 Jul 2006 18:10:02 +0200 with message-id <[EMAIL PROTECTED]> and subject line fixed in 2.33-1 has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: manpages-dev Version: 2.28-1 Severity: minor Tags: patch Glibc-doc has a bad example [0] and uses stdout instead of stdin (bug filed), so let's document the obvious. References [0] For rpmatch: file:///usr/share/doc/glibc-doc/html/libc_7.html#SEC121 --- - 2006-05-17 19:24:41.875493000 -0400 +++ /home/pryzbyj/man/getline.3 2006-05-17 19:24:04.000000000 -0400 @@ -21,7 +21,7 @@ .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" License. -.TH GETLINE 3 2001-10-07 "GNU" "Linux Programmer's Manual" +.TH GETLINE 3 2006-05-17 "GNU" "Linux Programmer's Manual" .SH NAME getline, getdelim \- delimited string input .SH SYNOPSIS @@ -34,19 +34,19 @@ .BI "ssize_t getdelim(char **" lineptr ", size_t *" n ", int " delim ", FILE *" stream ); .SH DESCRIPTION .BR getline () -reads an entire line, storing the address of the buffer containing +reads an entire line from \fIstream\fP, storing the address of the buffer containing the text into .IR "*lineptr" . -The buffer is null-terminated and includes the newline character, if a -newline delimiter was found. +The buffer is null-terminated and includes the newline character, if +one was found. .\" FIXME what happens if *lineptr is NULL but *n isn't zero ? .\" Answer: *n is ignored and a new buffer is allocated If .IR "*lineptr" -is NULL, then the +is NULL, then .BR getline () -routine will allocate a buffer for containing the line, which must be freed +will allocate a buffer for storing the line, which should be freed by the user program. Alternatively, before calling .BR getline (), @@ -55,9 +55,9 @@ .BR malloc ()\-allocated buffer .IR "*n" -bytes in size. If the buffer is not large enough to hold the line read in, +bytes in size. If the buffer is not large enough to hold the line, .BR getline () -resizes the buffer to fit with +resizes it with .BR realloc (), updating .IR "*lineptr" @@ -67,7 +67,7 @@ .IR "*lineptr" and .IR "*n" -will be updated to reflect the buffer address and size respectively. +will be updated to reflect the buffer address and allocated size respectively. .BR getdelim () works like @@ -78,7 +78,6 @@ .BR getline (), a delimiter character is not added if one was not present in the input before end of file was reached. - .SH "RETURN VALUE" On success, .BR getline () @@ -90,7 +89,6 @@ Both functions return \-1 on failure to read a line (including end of file condition). - .SH ERRORS .TP .B EINVAL @@ -101,7 +99,6 @@ is NULL, or .I stream is not valid). - .SH "EXAMPLE" .nf #define _GNU_SOURCE @@ -133,7 +130,6 @@ .BR getdelim () are GNU extensions. They are available since libc 4.6.27. - .SH "SEE ALSO" .BR read (2), .BR fgets (3),
--- End Message ---
--- Begin Message ----- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists.
--- End Message ---
