Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!ub!uhura.cc.rochester.edu!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.std.c
Subject: Re: functions within functions
Message-ID: <11681@pt.cs.cmu.edu>
Date: 26 Jan 91 23:41:10 GMT
References: <1991Jan22.081057.8567@ithaca.uucp>
Organization: Carnegie-Mellon University, CS/RI
Lines: 21

In article <1991Jan22.081057.8567@ithaca.uucp> 
	garry@ithaca.uucp (Garry Wiegand) writes:
>When the C standards committee was meeting, did they discuss allowing 
>the declaration of functions within functions?
>The name-space advantages should be obvious,...

Some of us have used languages that allowed this, and didn't like it.

Personal opinion: the outer functions get unreadable.

Software engineering opinion: the inner ones get undocumented or even
unexpected side effects, because they modify global variables.
(Global to them, that is.) 

Compiler writer's opinion: the calling convention now has to support
uplevel addressing. This is typically done at a cost of at least one
extra instruction per call. This distributed overhead is paid by all
calls - not just the ones that plan to uplevel-address - unless your
compiler does interprocedural optimization.
-- 
Don		D.C.Lindsay .. temporarily at Carnegie Mellon Robotics