Re: [bug-gnulib] standards.texi error function

[Paul Eggert]

> Date: Sun, 05 Dec 2004 09:38:41 -0500
> From: Richard Stallman <address@hidden>
>
> But I wonder what various packages are in fact using nowadays.
> For instance, could you send me some examples of code using the
> gnulib error module?

Here is one example, taken from coreutils:

          error (0, 0, _("`%s' option is obsolete; use `%s-%c %"PRIuMAX"'"),
                 argv[1], t_forever ? "-f " : "", t_count_lines ? 'n' : 'c',
                 *n_units);

where "n_units" is of type unsigned long long int *. PRIuMAX typically
expands to "llu", so this is typically roughly-equivalent to:

          error (0, 0, "`%s' option is obsolete; use `%s-%c %llu'",
                 argv[1], t_forever ? "-f " : "", t_count_lines ? 'n' : 'c',
                 *n_units);

I worry that this won't work on some modern hosts if "error" is coded
as the coding standards suggest, since unsigned long long int is often
wider than a pointer.

> movemail uses code much like that example, but passes only
> pointers, so it will still work.

Yes, I'd be surprised if a pointers-only usage stopped working.  I
suspect the only troublesome usages in practice will be values whose
widths differ from that of a pointer.

How about this patch instead?  It sidesteps the issue by removing the
somewhat-dated "error" example.

2004-12-05  Paul Eggert  <address@hidden>

        * standards.texi (CPU Portability): Integers and pointers no longer
        have the same width like they used to, so modernize the advice
        in this area.  Remove the "error" function.

Index: standards.texi
===================================================================
RCS file: /cvsroot/gnulib/gnulib/doc/standards.texi,v
retrieving revision 1.3
diff -p -c -b -w -r1.3 standards.texi
*** standards.texi      29 Nov 2004 18:37:47 -0000      1.3
--- standards.texi      6 Dec 2004 06:27:34 -0000
*************** while ((c = getchar()) != EOF)
*** 2687,2723 ****
    write(file_descriptor, &c, 1);
  @end example
  
! When calling functions, you need not worry about the difference between
! pointers of various types, or between pointers and integers.  On most
! machines, there's no difference anyway.  As for the few machines where
! there is a difference, all of them support Standard C prototypes, so you can
! use prototypes (perhaps conditionalized to be active only in Standard C)
! to make the code work on those systems.
! 
! In certain cases, it is ok to pass integer and pointer arguments
! indiscriminately to the same function, and use no prototype on any
! system.  For example, many GNU programs have error-reporting functions
! that pass their arguments along to @code{printf} and friends:
! 
! @example
! error (s, a1, a2, a3)
!      char *s;
!      char *a1, *a2, *a3;
! @{
!   fprintf (stderr, "error: ");
!   fprintf (stderr, s, a1, a2, a3);
! @}
! @end example
! 
! @noindent
! In practice, this works on all machines, since a pointer is generally
! the widest possible kind of argument; it is much simpler than any
! ``correct'' alternative.  Be sure @emph{not} to use a prototype for such
! functions.
! 
! If you have decided to use Standard C, then you can instead define
! @code{error} using @file{stdarg.h}, and pass the arguments along to
! @code{vfprintf}.
  
  @cindex casting pointers to integers
  Avoid casting pointers to integers if you can.  Such casts greatly
--- 2687,2700 ----
    write(file_descriptor, &c, 1);
  @end example
  
! It used to be ok to not worry about the difference between pointers
! and integers when passing arguments to functions.  However, on most
! modern 64-bit machines pointers are wider than @code{int}.
! Conversely, integer types like @code{long long int} and @code{off_t}
! are wider than pointers on most modern 32-bit machines.  Hence it's
! often better nowadays to use prototypes to define functions whose
! argument types are not trivial; if the functions accept varying
! argument counts or types they can be defined using @file{stdarg.h}.
  
  @cindex casting pointers to integers
  Avoid casting pointers to integers if you can.  Such casts greatly