From owner-freebsd-arch Mon Jul 9 6:56:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 4673837B405 for ; Mon, 9 Jul 2001 06:56:41 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA00599; Mon, 9 Jul 2001 15:56:29 +0200 (MET DST) Date: Mon, 9 Jul 2001 15:56:29 +0200 (CEST) From: Harti Brandt To: Bruce Evans Cc: Subject: Re: -fno-builtin In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 9 Jul 2001, Bruce Evans wrote: BE>On Mon, 9 Jul 2001, Harti Brandt wrote: BE> BE>> On Mon, 9 Jul 2001, Bruce Evans wrote: BE>> BE>> BE>I think it would work right except in broken code which "knows" that BE>> BE>strlen isn't a macro, e.g.: BE>> BE> BE>> BE> size_t (*p)(const char *s) = strlen; BE>> BE>> Why is that broken? My last copy of the ISO-C draft specifically states, BE>> that strlen is a function. (Not that I intend to use that construct. Just BE>> beeing curious). BE> BE>Does it really? Almost any library function can be implemented as a BE>(safe) macro (see section 7.1.4). I can't find any exception for BE>strlen. This possibility is not completely transparent to applications. BE>Code like the above should be aware of it. Workarounds are easy in BE>the above (just used "&strlen" or "(strlen)". Section 7.1.4 documents Well, hmmm, yes. The section on string.h states, that string.h contains ONE type and ONE macro and several functions, but 7.1.4 allows all functions to be macros. This means, that to take the address of ANY library function you have to do either: # undef func p = func; or p = (func); And p = &func; does not help. BE>these. Howver, I now remember a nasty example which shows why BE>implementations should not do this: BE> BE> len = strlen( BE>#ifdef FOO BE> "foo" BE>#else BE> "default" BE>#endif BE> ); BE> BE>This causes errors like: BE> BE>z.c:11: warning: preprocessing directive not recognized within macro arg BE>z.c:11: warning: preprocessing directive not recognized within macro arg BE>z.c:11: warning: preprocessing directive not recognized within macro arg BE>z.c: In function `main': BE>z.c:6: undefined or invalid # directive BE>z.c:8: undefined or invalid # directive BE>z.c:10: undefined or invalid # directive BE> BE>I only learned of this example a weeks or two ago. gcc-3.0 was reported BE>to make a very fundamental function (printf?) a macro. len = (strlen)( #ifdef FOO "foo" #else "default" #endif ); should work then. Thanks for the clarification, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message