Hi Bruno
Just a few remarks:
2)
- your changes would affect 19 files, Pauls only 12
- The ...in.h file are not the problem, but the resulting .h files. Their lines
might be shorter or even longer
Oh well, that supports your point, doesn't it?
5)
URLs ain't C code, so they may appear in comments. As long as the */ is on the
next line, truncation is OK.
URLs as strings can get split, with C's string concatenation.
char array[]="some long"\
" string";
Not nice maybe, but possible
Bye, Jojo
-----Original Message-----
From: Bruno Haible [mailto:br...@clisp.org]
Sent: Saturday, October 02, 2010 12:33 PM
To: Paul Eggert
Cc: Paolo Bonzini; Schmitz, Joachim; 'bug-gnulib'
Subject: Re: Fwd: sed porting trouble
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
