Date: Mon, 22 Jan 2001 23:51:22 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: imp@harmony.village.org (Warner Losh) Cc: eischen@vigrid.com (Daniel Eischen), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r Message-ID: <200101222351.QAA04791@usr08.primenet.com> In-Reply-To: <200101211927.f0LJRU901079@harmony.village.org> from "Warner Losh" at Jan 21, 2001 12:27:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> : > By the way, should it be __thread_sys_foo and __foo? Two underscores? > : > ISTR some rule about using a single leading underscore for file scope > : > (e.g. macros) and two for global scope. > : > : I don't recall that, but anything for file scope that isn't a macro > : can be static and not use the underscores. Macros are usually upper > : case anyways. > > ANSI C reserves _[A-Z]* and __[a-zA-Z] to the implementation space. > That leaves _[a-z] to the user name space, so Jacques is right about > that. > > I can quote chapter and verse if you really want me to. In the old days, all C cymbols were decorated with a leading underscore by the compiler, and the only space with undecorated functions at all was in assembly. The change-over happened at ELF-time. I'm not positive whether an undecorated symbol was considered to be in the namespace at all; I'm pretty sure it wasn't, since you couldn't write C code that called or was called by an undecorated name. In some ways, life is a lot less pleasent, without the C space being escaped this way. I guess that now the space has been flattened, this becomes an issue. To drag things back on subject, I don't oppose the changes, but I am worried about internal use exposure of functions that have been replaced (e.g. the strdup calling the "wrong" malloc example). One of the things I've seen happening historically on the library front is well-intended people trying to "protect" bad programmers from their own errors (the biggest example of this is the paper that claims core dumping when passing in a NULL instead of a zero length string to some functions, like strcmp). In the grand tradition of foot-shooting being allowed, because it lets you do clever, as well as stupid things, this says to me that all the symbols in the standard library should be weak, to permit their replacement by toe-targeting users. It also says to me that it's a profoundly bad idea to use #define'd things as if they were the symbols themselves, since it may not be the #define'ing header file that provides the function prototype for a replaced C library function provided by a user. So even if the "sigaction" problem _could_ be resolved, it probably _shoudn't_ be (IMO). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101222351.QAA04791>