Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!mit-eddie!ll-xn!ames!lll-lcc!pyramid!prls!mips!dce From: dce@mips.UUCP (David Elliott) Newsgroups: comp.bugs.4bsd,comp.unix.wizards Subject: Re: 4.3BSD stdio.h - sprintf() definition Message-ID: <526@quacky.UUCP> Date: Thu, 16-Jul-87 23:08:39 EDT Article-I.D.: quacky.526 Posted: Thu Jul 16 23:08:39 1987 Date-Received: Sat, 18-Jul-87 13:47:58 EDT References: <521@quacky.UUCP> Reply-To: dce@quacky.UUCP (David Elliott) Distribution: world Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 40 Xref: mnetor comp.bugs.4bsd:447 comp.unix.wizards:3284 In article <521@quacky.UUCP> dce@mips.UUCP (David Elliott) writes: >The 4.3BSD stdio.h contains the following item, found near the >bottom of the file: > > #ifdef vax > char *sprintf(); /* too painful to do right */ > #endif > >What is this doing here? What is supposed to be in apposition to >"vax"? > >What will break on my non-vax system if I remove the #ifdef? The responses I've received have all been correct, but none have actually answered my question. I know all about sprintf() returning an int in System V and returning its first argument in V7-derived systems. What my question is is why is it '#ifdef vax' and what isn't "vax"? In other words, is it this way because Sun and Gould and Pyramid and n other companies that wanted to be able to share the code decided to go with sprintf() returning an int? Our BSD-derived system is not a Vax, so the compiler doesn't define "vax". Will my code (defined as the entire set of 4.3BSD commands that are not totally DEC hardware dependent) break if I remove the #ifdef? Personally, I have a lot of problems with programs where people put in #ifdefs based on hardware types when the #ifdef should be based on something else. A good example (sorry Doug) is when I ported the BRL System V package to the MIPS system and found that some of the #ifdefs for "vax" applied (overall system architecture, usually vs. pdp11) and some didn't (byte order, in particular). The latter is even more of a pain when you realize that MIPS hardware can be configured for both big-endian and little-endian byte sex. -- David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce