The BSD make doesn't like line 20 of the Makefile
"Makefile", line 20: Need an operator
Fatal errors encountered -- cannot continue
can someone patch it. There's a space or something in what should be
an empty line. Just hitting 'x' in vi is enough to clear it and make BSD
make happy. Can't submit a patch for this since the mailer will probably
mess it up.
There's also some warnings that should be cleaned up,
httpd.c: In function `standalone_main':
httpd.c:257: warning: passing arg 2 of `accept' from incompatible pointer type
gcc -c -g http_request.c
gcc -c -g util.c
util.c: In function `get_remote_logname':
util.c:908: warning: passing arg 2 of `getpeername' from incompatible pointer type
util.c:910: warning: passing arg 2 of `getsockname' from incompatible pointer type
It looks like someone has tried fixing this since there's a
defined(BSD4_4) that's been added (line 186 of httpd.c) that isn't
in the NCSA code. BSD4_4 is defined in <sys/param.h> which is
getting picked up from httpd.h if __NetBSD__ is defined which is
a cludgy way of fixing things for 2 reasons. One, it's not NetBSD
specific and two, BSD4_4 is historically badly defined since public
releases of BSD between 4.3 and 4.4 had this set to 0.5 to signify
that some 4.4 features were present. It's thus completely useless
as a switch for 4.4 specific features since you can never guarantee whether
the specific feature your checking for actually exists on all systems
that define BSD4_4. Blame CSRG for this :-(
I was thinking of supplying patches for this but I don't have access to
enough different OS's to check which ones need the new declarations and
which one use the old. A few quick checks:
thrall:~% uname -a
SunOS thrall 4.1.3_U1 1 sun4m
int accept(s, addr, addrlen)
int s;
struct sockaddr *addr;
int *addrlen;
thor:~% uname -a
OSF1 thor V3.0 347 alpha
int accept (
int socket,
struct sockaddr *address,
int *address_len );
Tends to suggest that more systems use the newer style than the older and
that makes BSD4_4 even less appropriate. I'd suggest swapping the logic
of the code and making struct sockaddr sa_client; the normal case
and ifdef the systems that use the older style. Anyone know what these
systems are, can't find any here.
Incidentally, just for info. The correct way to determine what version
of BSD you're using is to check the BSD define against a specific date.
In 4.4lite it's
#define BSD 199306 /* System version (year & month). */
In OSF (same version as above) it's
#define BSD 198911 /* system version (year & month) */
this is a 4.3 based system and since, as I showed above it uses sockaddr
for the 2nd parameter to accept I strongly suspect that most OS's are
going to be this way around.
SunOS doesn't define BSD at all (pre SYSV SunOS of course).
I can't find a single SYSV system here to see what it does.
--
Paul Richards, FreeBSD core team member.
Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/
Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home)
Dept. Mechanical Engineering, University of Wales, College Cardiff.
"Makefile", line 20: Need an operator
Fatal errors encountered -- cannot continue
can someone patch it. There's a space or something in what should be
an empty line. Just hitting 'x' in vi is enough to clear it and make BSD
make happy. Can't submit a patch for this since the mailer will probably
mess it up.
There's also some warnings that should be cleaned up,
httpd.c: In function `standalone_main':
httpd.c:257: warning: passing arg 2 of `accept' from incompatible pointer type
gcc -c -g http_request.c
gcc -c -g util.c
util.c: In function `get_remote_logname':
util.c:908: warning: passing arg 2 of `getpeername' from incompatible pointer type
util.c:910: warning: passing arg 2 of `getsockname' from incompatible pointer type
It looks like someone has tried fixing this since there's a
defined(BSD4_4) that's been added (line 186 of httpd.c) that isn't
in the NCSA code. BSD4_4 is defined in <sys/param.h> which is
getting picked up from httpd.h if __NetBSD__ is defined which is
a cludgy way of fixing things for 2 reasons. One, it's not NetBSD
specific and two, BSD4_4 is historically badly defined since public
releases of BSD between 4.3 and 4.4 had this set to 0.5 to signify
that some 4.4 features were present. It's thus completely useless
as a switch for 4.4 specific features since you can never guarantee whether
the specific feature your checking for actually exists on all systems
that define BSD4_4. Blame CSRG for this :-(
I was thinking of supplying patches for this but I don't have access to
enough different OS's to check which ones need the new declarations and
which one use the old. A few quick checks:
thrall:~% uname -a
SunOS thrall 4.1.3_U1 1 sun4m
int accept(s, addr, addrlen)
int s;
struct sockaddr *addr;
int *addrlen;
thor:~% uname -a
OSF1 thor V3.0 347 alpha
int accept (
int socket,
struct sockaddr *address,
int *address_len );
Tends to suggest that more systems use the newer style than the older and
that makes BSD4_4 even less appropriate. I'd suggest swapping the logic
of the code and making struct sockaddr sa_client; the normal case
and ifdef the systems that use the older style. Anyone know what these
systems are, can't find any here.
Incidentally, just for info. The correct way to determine what version
of BSD you're using is to check the BSD define against a specific date.
In 4.4lite it's
#define BSD 199306 /* System version (year & month). */
In OSF (same version as above) it's
#define BSD 198911 /* system version (year & month) */
this is a 4.3 based system and since, as I showed above it uses sockaddr
for the 2nd parameter to accept I strongly suspect that most OS's are
going to be this way around.
SunOS doesn't define BSD at all (pre SYSV SunOS of course).
I can't find a single SYSV system here to see what it does.
--
Paul Richards, FreeBSD core team member.
Internet: paul@FreeBSD.org, URL: http://isl.cf.ac.uk/~paul/
Phone: +44 1222 874000 x6646 (work), +44 1222 457651 (home)
Dept. Mechanical Engineering, University of Wales, College Cardiff.