[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] Re: function portability documentation

From: Bruno Haible
Subject: Re: [bug-gnulib] Re: function portability documentation
Date: Mon, 22 May 2006 20:48:09 +0200
User-agent: KMail/1.5

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 :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]