From owner-freebsd-arch Mon Jan 22 15:52:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id C9C2F37B6DF for ; Mon, 22 Jan 2001 15:51:54 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id QAA04354; Mon, 22 Jan 2001 16:46:12 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAADSaisi; Mon Jan 22 16:45:47 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA04791; Mon, 22 Jan 2001 16:51:22 -0700 (MST) From: Terry Lambert Message-Id: <200101222351.QAA04791@usr08.primenet.com> Subject: Re: Request For Review: libc/libc_r changes to allow -lc_r To: imp@harmony.village.org (Warner Losh) Date: Mon, 22 Jan 2001 23:51:22 +0000 (GMT) Cc: eischen@vigrid.com (Daniel Eischen), n@nectar.com (Jacques A. Vidrine), arch@FreeBSD.ORG In-Reply-To: <200101211927.f0LJRU901079@harmony.village.org> from "Warner Losh" at Jan 21, 2001 12:27:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : > 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