From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:05
Patrick and Jason CC:'ed because they also have portability
issues and seem to have good ideas about how they should be
solved. Linus CC:'ed because he once expressed rather strongly
his dislike about autoconf.
Johannes Schindelin [off-list ref] writes:
I have three fixes in my personal tree without which git refuses to
compile:
- daemon.c needs a define or typedef for socklen_t.
I still keep that patch around (the patch was end of July), but
have not touched it only because I did not hear from you asking
about its inclusion.
- mailinfo.c needs to have a simple strcasestr implementation, because
10.2.8 (at least in my setup) is lacking it!
Yes, I've used it knowing that it is marked as a GNU extension,
hoping if somebody else can supply a patch to work it around ;-).
I am slightly reluctant to do autoconf [*1*], but I might be
tempted to take patches if it is done cleanly.
As a workaround until I am convinced otherwise and we go fully
autoconf, I am inclined to introduce a new subdirectory in the
source tree, compat/, which would house compat/linux.h,
compat/darwin.h, compat/solaris.h and friends, and have compat.h
symlink which points at one of those files.
[Footnote]
*1* ...although I admit that I once used to be an autoconf freak
and even had a few lines of my own code in the official autoconf
distribution. It was an ancient history, most likely before
libtool and automake came along. The last time I checked my
changes were all superseded.
Patrick and Jason CC:'ed because they also have portability
issues and seem to have good ideas about how they should be
solved. Linus CC:'ed because he once expressed rather strongly
his dislike about autoconf.
I personally think autoconf is the devils tool, and have had much more
luck with
- creating "compat" libraries that implement functions that some
configurations don't have.
Sometimes this involves renaming the function, in order to avoid
clashes with broken implementations of same.
- just ignoring the really broken systems (old HP-UX etc is terminally
diseased, and simply not worth worrying about)
autoconf generates an unreadable mess that can't be fixed. Doing it by
hand at least means you can fix it.
But hey, I don't care that much any more, since I'm not the sucker who
maintains it ;)
Linus
I have three fixes in my personal tree without which git refuses to
compile:
- daemon.c needs a define or typedef for socklen_t.
I still keep that patch around (the patch was end of July), but
have not touched it only because I did not hear from you asking
about its inclusion.
Side note: one simple solution for "socklen_t" is to just replace it with
"int".
Any operating system where socklen_t is anything else than "int" is
terminally broken. The people who introduced that typedef were confused,
and I actually had to argue with them that it was fundamentally wrong:
there is no other valid type than "int" that makes sense for it.
In case anybody cares: not only is "int" obviously "big enough" even on
some theoretical 16-bit architecture, so there's never any real _reason_
to use anything else.
But more importantly, the core BSD networking functions have historically
had declarations like
int accept(int s, struct sockaddr *addr, int *addrlen);
which means that if 'socklen_t' is ever anything else than "int", you'd
break all old applications. For no good reason.
Ergo, any operating system that has socklen_t != int is so broken that
it's simply not worth playing with.
(POSIX for a short while had _defined_ it to be the same as "size_t", I
really had to scream at some people over it, and told people that Linux
would never do anything that stupid. Apparently Linux was the first
64-bit operating system that people actually ever tried to use).
Linus
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:05
On Sun, 11 Sep 2005, Junio C Hamano wrote:
Patrick and Jason CC:'ed because they also have portability
issues and seem to have good ideas about how they should be
solved. Linus CC:'ed because he once expressed rather strongly
his dislike about autoconf.
Johannes Schindelin [off-list ref] writes:
quoted
I have three fixes in my personal tree without which git refuses to
compile:
- daemon.c needs a define or typedef for socklen_t.
I still keep that patch around (the patch was end of July), but
have not touched it only because I did not hear from you asking
about its inclusion.
quoted
- mailinfo.c needs to have a simple strcasestr implementation, because
10.2.8 (at least in my setup) is lacking it!
Yes, I've used it knowing that it is marked as a GNU extension,
hoping if somebody else can supply a patch to work it around ;-).
I am slightly reluctant to do autoconf [*1*], but I might be
tempted to take patches if it is done cleanly.
I've never noticed autoconf successfully improving portability, and it
seems to mostly obfuscate errors. E.g., the GNU binutils I was trying to
build recently, if you don't have "msgfmt", helpfully runs "no" instead.
Of course, that's autoconf being misused, but if binutils can't use it
correctly, I doubt any other project can keep from messing up.
Compatibility workarounds with simple detection scripts invoked by people
who find they actually need workarounds are probably best.
-Daniel
*This .sig left intentionally blank*
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:05
Hi,
On Sun, 11 Sep 2005, Linus Torvalds wrote:
I personally think autoconf is the devils tool, and have had much more
luck with
- creating "compat" libraries that implement functions that some
configurations don't have.
Sometimes this involves renaming the function, in order to avoid
clashes with broken implementations of same.
That was the original idea of autoconf...
- just ignoring the really broken systems (old HP-UX etc is terminally
diseased, and simply not worth worrying about)
... which is sometimes no option.
autoconf generates an unreadable mess that can't be fixed. Doing it by
hand at least means you can fix it.
A real pity! autoconf showed great promise in the first days. But then
they started using m4 and other crud crept in.
All that said, autoconf still makes it easy to make a program or library
portable. However, for git it would be overkill.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:05
Hi,
On Sun, 11 Sep 2005, Linus Torvalds wrote:
On Sun, 11 Sep 2005, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
I have three fixes in my personal tree without which git refuses to
compile:
- daemon.c needs a define or typedef for socklen_t.
I still keep that patch around (the patch was end of July), but
have not touched it only because I did not hear from you asking
about its inclusion.
Side note: one simple solution for "socklen_t" is to just replace it with
"int".
Any operating system where socklen_t is anything else than "int" is
terminally broken. The people who introduced that typedef were confused,
and I actually had to argue with them that it was fundamentally wrong:
there is no other valid type than "int" that makes sense for it.
Linus, we all know that you are always right. Only that in this case you
are just a little bit less right than usual. The introduction of this
typedef was a sane thing to do, for the same reason it is a sane thing to
use sensible variable names: documentation. It is _important_ that a
program be easy to read for others. As a further candy, you can grep and
even sed for socklen_t. Try that with every socklen_t substituted by int.
Ciao,
Dscho
Linus, we all know that you are always right. Only that in this case you
are just a little bit less right than usual. The introduction of this
typedef was a sane thing to do, for the same reason it is a sane thing to
use sensible variable names: documentation.
Nope.
Go through the history of that thing.
It wasn't introduced as "socklen_t". It was introduced as "size_t".
That was so horribly wrong that it's not even funny.
Documentation my ass. It's a matter of people thinking that the old
portable types aren't good enough, and that you have to make up new names
for everything in order to allow "portability" where different systems
have different ideas.
And it's ignoring the fact that true portability means "it just works".
"size_t" fundamentally didn't work.
And the really sad part is that before the standards bodies started
messing around with it, things really _did_ "just work". There was no
question at all about what kind of type to use.
These days, we sadly have some systems that just blindly followed the
standard, changed "int" to "size_t", and then when the standard was fixed,
changed "socklen_t" to be "size_t".
Don't believe me? Just google for "size_t" and "socklen_t", and weep.
All this confusion, and for what? Absolutely _zero_ upsides.
Basically, if a programmer feels like he needs to remind himself what the
variable was all about, how about using descriptive variable names? I
claim that
int addr_len;
is a lot more documentation than
socklen_t len;
and that the people who think that different type-name are "documentation"
are ignoring the fact that they are _also_ "confusing".
There's a virtue in simplicity. Abstraction is _not_ a virtue.
Linus
And the really sad part is that before the standards bodies started
messing around with it, things really _did_ "just work". There was no
question at all about what kind of type to use.
Btw, here's the result of the "documentation":
dnl check for Unix98 socklen_t
AC_MSG_CHECKING(for socklen_t)
AC_TRY_COMPILE([#include <sys/socket.h>
socklen_t x;
],[],[AC_MSG_RESULT(yes)],[
AC_TRY_COMPILE([#include <sys/socket.h>
int accept (int, struct sockaddr *, size_t *);
],[],[
AC_MSG_RESULT(size_t)
AC_DEFINE(socklen_t,size_t)], [
AC_MSG_RESULT(int)
AC_DEFINE(socklen_t,int)])])
isn't that nice? Before the "documentation", you could just use
int accept(int, struct sockaddr *, int *);
and it would work. EVERYWHERE. No autoconf crap required.
So don't talk to me about documentation. It's pure and unadulterated crap.
Linus
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:05
Hi,
On Sun, 11 Sep 2005, Linus Torvalds wrote:
On Sun, 11 Sep 2005, Linus Torvalds wrote:
quoted
And the really sad part is that before the standards bodies started
messing around with it, things really _did_ "just work". There was no
question at all about what kind of type to use.
Btw, here's the result of the "documentation":
[lots of ugly code]
isn't that nice? Before the "documentation", you could just use
int accept(int, struct sockaddr *, int *);
and it would work. EVERYWHERE. No autoconf crap required.
So don't talk to me about documentation. It's pure and unadulterated crap.
Okay. I have to admit that what you presented is a good argument.
However, the code I usually have to deal with is comparable to what you
read on www.thedailywtf.com, and even a "socklen_t l;" with that type of
code is more helpful than a simple "int l;", which might even be reused as
something completely different.
That said, in a well designed and clean project, such as git, such types
of documentation should not be necessary.
Ciao,
Dscho