Thanks for that suggestion and the work in generating that nice patch.
One general comment is that there is a lot of duplicate text that
perhaps could simply be replaced by an index. E.g., instead of this:
@item btowc
On Windows systems, @code{wchar_t} is a 16-bit type and therefore cannot
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},
Ralf Wildenhues wrote:
> so here we go, quickly:
Thanks, Ralf, for proofreading. I've integrated many of your remarks.
> - Should the entries be indexed? I would prefer so.
Yes, certainly. Probably this is also a good occasion to split the
"program index" and the "function / header index". IMO
Bruno, that's great work. I did some proofreading and found some
minor things to point out.
Bruno Haible <[EMAIL PROTECTED]> writes:
> + @code{basename} assumes file names in POSIX syntax; it does not with file
> + names in Windows syntax.
"...does not" work "with file..."
> + @item btowc
> +
Hi Bruno,
* Bruno Haible wrote on Mon, May 22, 2006 at 02:13:52PM CEST:
>
> 2) Who should maintain this section in the future?
>
> Why does the section currently have only 20 entries, when an up-to-date
> list of portability problems has more than 200 entries? I think the answer
> is that the au
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi,
>
> Inspired by Paul Eggert's new chapter about "Portable C and C++ Programming",
> I went out and collected portability notes and pitfall reminders for over
> 200 among the 1116 POSIX functions. (Attached.)
Thanks, this seems incredibly useful!
Per
