[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: sed porting trouble
From: |
Bruno Haible |
Subject: |
Re: Fwd: sed porting trouble |
Date: |
Sat, 2 Oct 2010 12:33:19 +0200 |
User-agent: |
KMail/1.9.9 |
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
- Re: Fwd: sed porting trouble, (continued)
- Re: Fwd: sed porting trouble, Simon Josefsson, 2010/10/05
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/05
- Re: Fwd: sed porting trouble, Paul Eggert, 2010/10/04
- Re: Fwd: sed porting trouble, Jim Meyering, 2010/10/05
- Re: Fwd: sed porting trouble, Paul Eggert, 2010/10/01
- Re: Fwd: sed porting trouble, Jim Meyering, 2010/10/02
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: Fwd: sed porting trouble, Paolo Bonzini, 2010/10/02
- Re: Fwd: sed porting trouble,
Bruno Haible <=
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/02
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: Fwd: sed porting trouble, Paul Eggert, 2010/10/03
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/03
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/02
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: Fwd: sed porting trouble, Bruno Haible, 2010/10/02
- RE: Fwd: sed porting trouble, Schmitz, Joachim, 2010/10/02
- Re: libfloss on HP NonStop, Bruno Haible, 2010/10/02