Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!hao!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: how do I initialize a function pointer to be NULL ? Message-ID: <8569@mimsy.UUCP> Date: Mon, 14-Sep-87 16:11:14 EDT Article-I.D.: mimsy.8569 Posted: Mon Sep 14 16:11:14 1987 Date-Received: Wed, 16-Sep-87 00:40:47 EDT References: <197@tiger.Princeton.EDU> <27742@sun.uucp> <2236@emory.uucp> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 29 Keywords: NULLFUNC In article <2236@emory.uucp> platt@emory.uucp (Dan Platt) writes: >Actually, depending on the model (the IBM machines have a segmented >addressing scheme), NULL is defined as 0 if the memory is in small or >medium models, and is defined as 0L in compact and large models. This is a bogosity intended to make broken code work. It is unnecessary and potentially confusing. >As far as the function is concerned, it doesn't care what kind of >pointer is passed to it; it just passes an address. Here is the essence of the confusion. This is *not* *true*. Despite the relative weakness of its typing, C is a typed language. Functions do not `just pass addresses' to other functions; functions pass `pointer to 's, such as `pointer to function returning int'. In small models, IBM PC pointers-to-functions-returning-int occupy 16 bits; in large models, these pointers occupy 32 bits. That `0' and `0L' happen to exactly correspond to those 16 and 32 bit pointer-to-nil-function-returning-int values is what might be called an accident of design. If you write type-correct code in the first place, you will not depend upon this carefully engineered accident, and hence will not be burned when a different C implementation cannot do this for you. [We used to hear `all the world's a Vax'; is it now to be `all the world is PC compatible'?] -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris