Re: Fwd: sed porting trouble

[Bruno Haible]

Hi Paul,

> I agree about the "Sigh", but it's better to do that than to play with
> unportable #pragmas.

I vehemently disagree, for five reasons:

1) This handling of NonStop's misfeature would put us back to the 1960ies
   where Fortran was invented with column-dependent syntax. Even the
   Fortran people got over it, with Fortran 95. It IS now widely accepted
   that source code can be free-form, so that columns don't matter. It IS
   common standard to use terminal emulators in X windows which can be
   resized to more than 200 columns.

2) Reliability. Your patch "fixes" 24 places. But how long will it take for
   another commit to reintroduce a line longer than 80 columns?

   This command

$ wc -L arpa_inet.in.h ctype.in.h locale.in.h math.in.h netinet_in.in.h \
  regex.h sched.in.h signal.in.h spawn.in.h stdarg.in.h stddef.in.h \
  stdio.in.h stdlib.in.h string.in.h sys_socket.in.h sys_stat.in.h \
  sys_time.in.h sys_wait.in.h time.in.h wchar.in.h
    75 arpa_inet.in.h
    79 ctype.in.h
    80 locale.in.h
   115 math.in.h
    74 netinet_in.in.h
    79 regex.h
    76 sched.in.h
    78 signal.in.h
   104 spawn.in.h
    74 stdarg.in.h
    74 stddef.in.h
    86 stdio.in.h
   164 stdlib.in.h
    82 string.in.h
   101 sys_socket.in.h
    84 sys_stat.in.h
    77 sys_time.in.h
    79 sys_wait.in.h
    77 time.in.h
   213 wchar.in.h

shows that while many files have less than 80 columns, there is also a
tendency to use more columns occasionally.

Even in the ChangeLog file, where we try really hard to keep the 80 column
limit, we have 20 lines which are longer:

  $ grep -n '   .\{73,100\}' ChangeLog | wc -l
  20

One of them is in an entry from you yourself:
33020:  See 
<http://lists.gnu.org/archive/html/bug-gnulib/2007-12/msg00149.html>.
No, I'm not asking to change it. It's OK as it is.

3) A limit on the line length invariably creates a pressure to use short
   identifiers - a bad habit which we have finally nearly eliminated from our
   minds.

4) Readability. You say
> I can't easily parse this:
> 
> #if defined __need_mbstate_t || defined __need_wint_t || (defined __hpux && 
> ((defined _INTTYPES_INCLUDED && !defined strtoimax) || defined 
> _GL_JUST_INCLUDE_SYSTEM_WCHAR_H)) || defined _GL_ALREADY_INCLUDING_WCHAR_H

   The results of following an 80-columns limit does not produce readable code
   either. These snippets are taken from glibc's header files.

extern int posix_spawnattr_setschedparam (posix_spawnattr_t *__restrict __attr,
                                          const struct sched_param *
                                          __restrict __schedparam) __THROW;

extern unsigned long int __wcstoul_internal (__const __gwchar_t *
                                             __restrict __nptr,
                                             __gwchar_t **
                                             __restrict __endptr,
                                             int __base, int __group)
  __THROW __nonnull ((1)) __wur;

extern int pthread_attr_getinheritsched (__const pthread_attr_t *__restrict
                                         __attr, int *__restrict __inherit)
     __THROW __nonnull ((1, 2));

   It would be more readable if each parameter was specified on one line, even
   if this requires 90 or 95 columns.

   Or this one, that your proposed patch would introduce:

_GL_CXXALIAS_SYS_CAST2 (strcasestr,
                        char *, (const char *haystack, const char *needle),
                        const char *, (const char *haystack,
                                       const char *needle));

   This is a good example of the damage that artificial line breaking does:
   The same parameter list is written in two different looking ways.

5) There are cases where you can't even reasonably insert a line break at all.
   Namely when you have an URL longer than 80 characters.

Bruno