bill@proxftl.UUCP (T. William Wells) (08/27/88)
In article <371@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes:
: > "The declaration of an identifier for a function that has block scope
: > shall have no explicit storage-class specifier other than extern."
:
: is it too late to get this changed back in the standard? this seems to
: be a serious mis-feature. i have used function declarations inside
: of functions to document where a function is used. now they are telling
: us we can't document static functions in this fashion.
Yes. I made a complaint about the change in the linkage rules,
but they made it clear (for "reasons" explained in the Rationale)
that they were not going to fix it.
I have come to the conclusion that the only proper way to use
functions in ANSI C is to place prototypes for all functions
defined or referenced in a source file either in included files
or at the top of the file.
This seems to be the only simple solution to the problem. Argh.
: i know this has been discussed before, but what exactly is The Committee
: trying to do to C?
Standardize it. Sometimes by forcing the language to be usable
on lowest-common-denominator class implementations. This is the
*only* reason given for this brain-damage. Since the Rationale
also asserts that "Existing code is important, existing
implementations are not." (p.2, section 1.1) I find their
rationalization to be sheer hypocrisy.
In general, the committee has done a good job, but I can't
(won't, actually, since I save those words for people with no
apparent redeeming characterics) express the depths of my disgust
or the degree of my condemnation for this moral failure on the
part of the committee.
: this one change will result in virtually all of the
: code i've written being broken. [ along with much code i've not written
: but still have to maintain ] the resulting language will share only the
: name with the original language.
I wouldn't go quite so far; I have had no problem adapting my
coding habits to be compatible with existing practice and with
the ANSI standard.
---
Bill
novavax!proxftl!billiiit-sh@cybaswan.UUCP (Steve Hosgood) (08/31/88)
In article <1757@microsoft.UUCP> microsof!markro writes: >..... here is (I believe) the appropriate section from the >May 88 draft standard (3.5.1, pg 56, lines 19-20): > > "The declaration of an identifier for a function that has block scope > shall have no explicit storage-class specifier other than extern." In article <371@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >is it too late to get this changed back in the standard? this seems to >be a serious mis-feature. i have used function declarations inside >of functions to document where a function is used. now they are telling >us we can't document static functions in this fashion. > >i know this has been discussed before, but what exactly is The Committee >trying to do to C? this one change will result in virtually all of the >code i've written being broken. [ along with much code i've not written >but still have to maintain ] the resulting language will share only the >name with the original language. I agree, Joe Bob, I've got the same problem exactly! This had better get to the the comp.std.c group *now* so they can discuss it before it *is* too late. I think the compiler is correct according to the standard, but the standard is broken. However, the compiler *ought* to produce an error message. After all, declaring a function static within a block would mean that it would have to be *defined* within that block in order to be both visible and usable. However, C has no mechanism for declaring functions within blocks, so at very least the static declaration should cause an error message to that effect. Someone's pinched my K&R, but I'm sure it says that this is a special case for the reasons I've mentioned above. ANSI have *got* to decide one way or another, I hope they change lines 19-20, page 56! I hope no-one objects, but I've directed follow-ups to comp.std.c Even if ANSI are right, I think you'd agree that this is a standards problem now, not just MSC. -----------------------------------------------+------------------------------ Steve Hosgood BSc, | Phone (+44) 792 295213 Image Processing and Systems Engineer, | Fax (+44) 792 295532 Institute for Industrial Information Techology,| Telex 48149 Innovation Centre, University of Wales, +------+ JANET: iiit-sh@uk.ac.swan.pyr Swansea SA2 8PP | UUCP: ..!ukc!cybaswan.UUCP!iiit-sh ----------------------------------------+------------------------------------- My views are not necessarily those of my employers!
haugj@pigs.UUCP (The Beach Bum) (09/05/88)
In article <697@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: >Well, consider the related question: who should have to deal with >the pain caused by systems that make one pass compilation >difficult: every user of ANSI C, or those people charged with the >writing of a C compiler for those systems? is this the claimed rational? declaring functions as static local to a referencing function _can_ be handled with single pass compilation. the compiler may be easier to write than with that feature included, but with it included, the compiler could still be single pass. -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
bill@proxftl.UUCP (T. William Wells) (09/08/88)
In article <391@pigs.UUCP> haugj@pigs.UUCP (The Beach Bum) writes: : In article <697@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: : >Well, consider the related question: who should have to deal with : >the pain caused by systems that make one pass compilation : >difficult: every user of ANSI C, or those people charged with the : >writing of a C compiler for those systems? : : is this the claimed rational? declaring functions as static local : to a referencing function _can_ be handled with single pass compilation. : the compiler may be easier to write than with that feature included, : but with it included, the compiler could still be single pass. The specific example they give is: a one pass compiler that produces assembly code output and has to treat internal names differently from external names. The problem is that when first encountering the function name, the compiler has to decide *right then* whether the name has external linkage or not. It's a rotten justification. --- Bill novavax!proxftl!bill