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