On 10 Jul, Roger Leigh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Malc Arnold <[EMAIL PROTECTED]> writes: > > > On 09 Jul, Roger Leigh wrote: > >> > >> * It's written in K&R C. This has been obsolete for 16 years, and > >> must be converted. GCC will not support K&R forever; -traditional > >> has already been removed. > > >> * It wrongly prototypes all the functions and exported variables from > >> the standard library, including errno. This is *totally broken*, > >> and will result in a non-functional program on a modern glibc, and > >> will also fail on amd64. > > > > Why do you think that? Since it doesn't result in a non-functional > > program, it would seem you're plain wrong here. > > Not at all. "extern int errno" is broken on NPTL libc, because it's > actually thread-local (i.e. it's effectively "int __thread errno"), > rather than global. The correct solution is to include <errno.h>. > > What I don't get is that you *do* include the standard headers, but > then you go and prototype their content *again*, by hand. This is > obviously prone to breakage when the header changes, as is the case > for errno.
Because different systems include different things in their standard headers. Everything that is *guaranteed* to be declared in the header files isn't declared in the actual af source. Unfortunately that is widely variable across systems and compilers. > > I have to admit that I haven't tested it on amd64, but since it > > compiles and runs fine on several 64-bit architectures I see no need > > to worry. > > Because the default return type of a non-prototyped function is "int", > this will truncate returned pointers to 32 bits. On a platform using > 64-bit pointers, this is a disaster. You may have avoided this one. I have. You can guarantee that if it's a pointer, it's declared. The need to do this on K&R compilers is the whole reason those libraries are there. > > What you are talking about here is fine for Debian and Linux, but not > > so good for other architectures. This is *not* a Linux program. It's > > a Unix program that runs fine under Linux. It also runs just fine on > > pretty much anything else since v7 Unix. > > Which has been dead for 25 years. Please ask yourself how many folks > *today* use a K&R compiler. Of those, how many could switch to GCC? Most. Not necessarily all. > Portability is a good goal, but there are limits. You are now getting > to be point where you do need to do some work to make it work on > current systems. The hacks you were using are no longer appropriate, > or portable. There are tools like ansi2knr to help with porting to > older systems, and I suggest you take a look at them. > If you need to support older compilers, ansi2knr will convert the > source on the fly. It's distributed as part of automake, for example. Last time I looked at ansi2knr it wouldn't work with af. It made an awful lot of assumptions about code, some of which weren't true of the af source. It may have improved since then. > > Well, since I am upstream I'll answer that one. If you think that > > mindlessly changing a program in a manner that may break portability > > to anything except the one true system is acceptable then you need > > to be introduced to the cluebat. The core of af was written on a > > system that didn't have an ANSI compiler available. > > Right. But things have moved on since then. I'm not suggesting > "mindless" changes, just porting to ISO C90, i.e. ANSI C. This, as I > explained above, need not exclude K&R compilers. If I make the changes you listed to the code, it won't compile under a K&R compiler. > Right now, af fails to build with the sid toolchain. The bug is a > year old, without any prior response by yourself, and so I would > greatly appreciate you taking some action to fix it. I've already fixed my local copy, before you even sent your mail. I'm testing it (at this instant) before I upload. Cheers, -- M a l c . . . | "Just because you can slash your wrists on ([EMAIL PROTECTED]) | it doesn't mean it's cutting edge." -- Me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
