Ben Pfaff wrote: > I did some proofreading and found some minor things to point out.
Thanks. I'm fixing most of these. > Should "b" be @samp{b}? @code{"b"} is better here: the 'b' must be part of C string. > > + On Windows, this function doesn't support the @code{'} flag and the > > @code{hh}, + @code{ll}, @code{j}, @code{t}, @code{z} size specifiers. > > The Texinfo manual says @samp{} should be used for single > characters, for what it's worth. Dunno if you care. @samp{'} looks too awful. > Is "testsuite" one word? Google comparison: "testsuite" -> 32 million hits, "test suite" -> 26 million. So it seems ok. > > + @item open > > + On Windows, this function returns a file handle in @code{O_TEXT} mode > > by + default; this means that it translates '\n' to CR/LF by default. > > Use the + @code{O_BINARY} flag if you need reliable binary I/O. > > It seems slightly odd to mix C and character name notation. Well, it's talking about C character names on one hand and byte values on the other hand. > Perhaps "translates '\n' to '\r\n'" or "adds a carriage return > before every new-line"? Well, that's not actually what it does. The '\n' and the CR/LF are on different conceptual levels. > > + @item poll > > + On MacOS X 10.4.0 and AIX 5.3, this function doesn't work on special > > files + like @file{/dev/null} and ttys like @file{/dev/tty}. > > How does it fail? Too weird, you don't want to know ;-) > Gnulib has a socklen module that should perhaps be mentioned here > (and in other references to socklen_t). > ... > Is it worth listing which socket options are specified in > the Unix standards, or can even those not be depended upon? > ... > It would be nice to be more specific, if possible naming kernel > or glibc versions as prerequisites for correct behavior. > ... > You could mention the Gnulib stdarg module here. Good points. In this first draft, I limited myself to listing the problems. Showing solutions comes afterwards. I think we can discuss these things on bug-gnulib. It's too many topics to discuss all at once, though :-) Bruno