Which C Standard?
In the early days of Berkeley UNIX (pre-Version 6), C was not yet standardized. For example, types such as "unsigned" did not even exist--instead, arithmetic was done on "char*" types. Partly as a result of early portability experiments, Bell Labs eventually revised C to conform to a definition devised by Brian Kernighan and Dennis Ritchie (K&R), two Bell Labs scientists. Their book, The C Programming Language (Prentice-Hall, 1978), defined what C was for almost the next ten years. Berkeley then adopted this new "standard" for all related prior code and all new code when it began to put a serious effort into developing new UNIX functionality. As the use of C has grown, its popularity has necessitated the evolution and solidification of an ANSI specification of the language and its semantics. Pre-K&R adherents to C, ideological to a fault, have frequently found much amusement in this obsession with standards. After all, they originally had to fight management and funding group opposition to its use (partly on the grounds of "standardization") in many major projects for which it was well suited, and had to live with the barrage of Fortran, Pascal, and then Ada efforts to displace C as the preeminent systems programming language of the day. Perhaps those groups might finally agree that C will be around for yet a few years to come!|
What does this have to do with 386BSD? Plenty! It seems that some believe it is time to move BSD, kicking and screaming, into the ANSI C world, but others are still adherents of the K&R viewpoint. Since the K&R portable C compiler is still used for slowly dying architectures and is yet a force to be reckoned with, 386BSD must find a median solution. 386BSD has an eye towards the future, however, so a concerted effort has been made with 386-dependent code to work within the new ANSI C format, while remaining compatible with K&R C in common code by virtue of #ifdefs.
GCC attempts to remedy this conflict by providing a traditional mode, but this is inadequate to our needs. GCC, it turns out, is not perfectly "traditional," as it favors ANSI semantics. (This should actually be no surprise, as it is difficult to be complete in this regard.) As such, it is another source of "silent" bugs that one should be aware of because the majority of the BSD code was written to older standards.