Re: pwrite module

[Bruno Haible]

Hi Peter,

> There is a pread module, but no pwrite. This is a mostly mechanical
> patch, copying the pread bits and s/read/write/ and copying pwrite.c
> from glibc.

Thanks. I committed this in your name.

You certainly hate paperwork as much as I do. I don't see a copyright
assignment for you and gnulib on file so far, only for some autotools
projects. Would you mind starting the process of a copyright assignment
for gnulib? You find the form to print in gnulib/doc/Copyright/.

> 2010-05-05  Peter O'Gorman  <address@hidden>
> 
>         New module pwrite
>         * doc/posix-functions/pread.texi: Mention gnulib module.
>         * doc/posix-functions/pwrite.texi: Likewise.
>         * MODULES.html.sh: Add pwrite.
>         * lib/unistd.in.h: Likewise.
>         * m4/unistd_h.m4: Likewise.
>         * modules/unistd: Likewise.
>         * tests/test-unistd-c++.cc: Likewise.
>         * lib/pwrite.c: Likewise.
>         * m4/pwrite.m4: Likewise.
>         * modules/pwrite: Likewise.
>         * modules/pwrite-tests: Likewise.
>         * tests/test-pwrite.c: Likewise.
>         * tests/test-pwrite.core: Likewise.
>         * tests/test-pwrite.sh: Likewise.

I did a few minor changes while committing your patch:

- Split it into three patches. The pread change is independent and
  therefore belongs in a separate patch. Also the test suite module can
  be committed separately.

- I did not commit a file tests/test-pwrite.core, because you did not provide
  it. (I guess it would have been a bit too large for a mail :-).)

- Your ChangeLog entry was incomplete. Please take the time to write a decent
  ChangeLog entry. Doing this is a good opportunity to catch small mistakes
  as well.

- I did not commit the part of MODULES.html.sh, because that change did not
  make sense to me. The meaning of the variables you modified are not related
  to the contents of gnulib, and ought to remain sorted alphabetically.

- In the documentation, we list the platforms in a particular order: First
  come the free Unix systems, then the proprietary Unix systems, then the
  Win32 platforms, and the hobby/misc systems at the end. For the complete
  list, see doc/posix-functions/posix_trace_attr_init.texi.

- In pwrite.texi: I moved the portability problem from the section
  "not fixed by gnulib" to the section "fixed by gnulib".

- pwrite.c: I replaced the copyright header with a GPL3 header. The effective
  copyright is the one in the module description.

- pwrite.c: I made <unistd.h> the first included header after <config.h>. This
  is a "best practice" of gnulib.

- pwrite.m4: s/pread/pwrite/

- modules/pwrite: s/read/write/

- modules/pwrite-tests: Mention the main test file first.

- tests/test-pwrite.c: Put a space before opening parentheses (GNU style).

- tests/test-pwrite.sh: Removed the pipe, since the test program does not
  access stdin. This file could be removed now, leaving only test-pwrite.c.
  What do you think?

Last not least, at your company <thewrittenword.com> you seem to have machines
with AIX, HP-UX, IRIX, Tru64. Among the gnulib developers, it is hard to have
access to such platforms, but such access is often needed when we want
  a) to investigate problems that have been reported by other people,
  b) produce code that runs well on these systems (latest example: 
setproctitle).
Things were simpler at the times when compilefarm.sf.net and testdrive.hp.com
existed. Can you somehow help us on this topic?

Bruno