brianc@cognos.uucp (Brian Campbell) (08/10/87)
Does asld enforce any restrictions on the size of the text or data segments? I was trying to get filecomp (from the Turbo C distribution) to compile under minix and couldn't understand why it kept blowing up on me. I finally did a `size filecomp` and found that the bss area had a negative size! How come asld (or even cc -- it was one large array) didn't catch this? Also, I finally tracked down my last problem with less under minix. It involved a clash between putc() as defined in less and the libc.a version. sprintf() calls putc() to output characters in the format string, but the putc() that got used was less's which messed up my prompt string. Is it really all that unusual that for a program to define its own putc() that it is acceptable for sprintf() [and who knows what else] to break in the process? And while I'm here ... I thought sprintf() was supposed to return the number of characters copied... not the address of the buffer. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: 3755 Riverside Drive, Ottawa, Ontario, K1G 3N3 (613) 738-1440 fido: sysop@163/8
chet@cwruecmp.UUCP (08/14/87)
In article <1237@cognos.UUCP> brianc@cognos.uucp (Brian Campbell) writes: >And while I'm here ... I thought sprintf() was >supposed to return the number of characters copied... not the address of >the buffer. With BSD systems (at least on the VAX), sprintf() returns a pointer to the buffer because it's "too painful to do right", which, I assume, means returning the number of characters copied into the buffer. I think Sys V systems return the number of characters. I assume this is because V7 had sprintf() return a pointer to the buffer, and BSD followed that. Now that there is so much BSD kernel (and other) code, at least on the VAX, that depends upon or assumes that sprintf() returns a pointer, it's too tough to follow AT&T's lead and return the number of characters copied. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ chet%cat /usr/include/stdio.h . . #ifdef vax char *sprintf(); /* too painful to do right */ #endif ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chet Ramey Internet: chet@cwru.edu UUCP: {...}!cbosgd!cwruecmp!chet BITNET: ramey%cwru20@cu20b He was a sharp guy...He lived on the edge of town...
wnp@mcomp.UUCP (08/14/87)
cognos.UUCP!brianc (Brian Campbell) writes: > ... > Is it really all that unusual that for a program to define its own > putc() that it is acceptable for sprintf() [and who knows what else] to > break in the process? I don't know how usual or unusual it is, but any redefinition of one of the standard library functions which changes its behavior is definitely unwise, and flies in the face of the very purpose of having a STANDARD library. > ... And while I'm here ... I thought sprintf() was > supposed to return the number of characters copied... not the address of > the buffer. You are right on that one according to all the references I looked it up in. ----------------------------------------------------- Wolf N. Paul, 290 Dogwood, Plano, Tx. 75075 UUCP: ihnp4!{convex, killer}!mcomp!wnp Phone: (214) 578-8023 W.U.ESL: 6283-2882