dce@mips.UUCP (David Elliott) (07/16/87)
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?
--
David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dcechris@mimsy.UUCP (Chris Torek) (07/16/87)
In article <521@quacky.UUCP> dce@mips.UUCP (David Elliott) writes: >The 4.3BSD stdio.h contains the following item ... : > #ifdef vax > char *sprintf(); /* too painful to do right */ > #endif >What is this doing here? `Right' is int sprintf(); /* per ANSI (draft) std & SysV */ Unfortunately, there are programs that rely upon the old return value. Well, they will have to change sometime. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
jim@applix.UUCP (Jim Morton) (07/17/87)
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"? That's funny, in my Usenix 4.3 BSD manuals, which say "VAX Version" on the title page, sprintf() is shown as an int routine. And in System V.3 stdio.h, it's declared as an int. (Always was int in Sys V, but now stdio.h enforces it). -- -- Jim Morton, APPLiX Inc., Westboro, MA UUCP: ...seismo!husc6!necntc!m2c!applix!jim ...seismo!harvard!m2o 3ans 10 - s
dce@mips.UUCP (David Elliott) (07/17/87)
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
guy%gorodish@Sun.COM (Guy Harris) (07/17/87)
> 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? We wanted to, but it caused too many problems. I suspect that may be why the #ifdef is there. > 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? Probably not. It probably won't break if you leave it in, either; programs that don't depend on that characteristic of "sprintf" will get "lint" complaints, and programs that *do* depend on it will get compile-time warnings. There's really no point in using that feature, so you might just want to change those programs not to do so. > 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 trouble here is that there is no system-supplied predicate for testing the byte-order of a particular machine, so those people didn't really have any choice other than to require anybody doing the porting to set up the Makefile or some include file to specify the byte sex. There *should* either be a predicate built into the C preprocessor/compiler or a #define constant in some system include file; the trouble with putting in #if vax || iAPX286 || i386 ... or #if mc68000 || m68k || sparc ... is that 1) there's no guarantee that there will be a unique #define for a particular machine (consider "mc68000" vs. "m68k") and 2) it doesn't help when a new machine comes along. (I don't even know what the magic predefine is for the NS32K series, or even if everybody uses the same one, so I didn't put it in up there; I don't know if there *is* one for the WE32K series - AT&T seems to use stuff like #if u3b20 || u3b2 || u3b5 || u3b15 || ... but enumerating all the 3Bs seems like a silly way of defining the set of machines using the WE32K (unless, of course, that set stops growing at some point, which is certainly possible).) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
chris@mimsy.UUCP (Chris Torek) (07/18/87)
In article <526@quacky.UUCP> dce@mips.UUCP (David Elliott) writes: >What my question is is why is it '#ifdef vax' and what isn't "vax"? It is `#ifdef vax' because it was a quick hack. Other people have already fixed their sprintf()s, but fixing it for 4.3BSD was `too painful'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/18/87)
In article <526@quacky.UUCP> dce@quacky.UUCP (David Elliott) writes: >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, ... I too have a lot of hassle because of these issues when porting software. The problem as I see it is that there isn't a standard list of attributes, so one needs to establish standards for one's own software to treat these orthogonal attributes independently. Unfortunately much existing software treats the system type as the only selector. Most of that cruft in the BRL UNIX System V emulation was simply inherited from the original AT&T code; I didn't have time to thoroughly overhaul everything. Our latest shell sources, however, are almost free of this kind of conditionalization. Recent AT&T SGS packages also are much better about these things. Maybe there's hope!