Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!haven!mimsy!chris From: chris@mimsy.umd.edu (Chris Torek) Newsgroups: comp.unix.questions Subject: Re: stdio.h & sprintf question Message-ID: <24828@mimsy.umd.edu> Date: 11 Jun 90 15:28:51 GMT References: <13081@smoke.BRL.MIL> Distribution: comp Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 29 In article <13081@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>char *sprintf(); /* too painful to do right */ >... is an artifact from an early implementation of sprintf() ... >While Berkeley didn't [fix sprintf] for quite a while, because as the >comment indicates it would require tracking down all uses in >applications and fixing them, I think 4.4BSD plans to track the C >standard, which specifies int-valued. The type of sprintf was changed either for or immediately after the `tahoe' release of 4.3BSD. now contains an int declaration, without any mysterious `#ifdef vax'. The number of programs that subsequently fail to compile and/or run is astonishing (this includes, e.g., X11R3). In most cases it is simply a matter of removing the declaration `char *sprintf();' from some source modules; in some cases it requires expanding things, e.g., from return (sprintf(buf, "%s/%s", dir, file)); to (void) sprintf(buf, "%s/%s", dir, file); return (buf); and it is the latter that is painful. (No, there is no `osprintf' function that acts like sprintf but returns its first argument, though if someone argued sufficiently hard for it we might be convinced to put one in -lcompat.) While 4.4BSD will not be completely ANSI compliant (even when using gcc and -D_ANSI_SOURCE), we have at least started the task. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris