[comp.lang.c] A Modest Proposal

drw@cullvax.UUCP (Dale Worley) (07/13/87)

Of all the features of C that are gross, the grossest one is NULL.  As
just a sample of its ugliness, consider the rule that "a pointer can
be compared against a zero integral constant".  This is the only place
in C in a comparison where (a) a constant can't be replaced by an
expression of the same value, or (b) a constant can't be replaced by a
constant with a different value but the same type.

What I propose is the NULL be made into a keyword of the language
which acts like a constant and whose value is a pointer, and
eliminating "0" as the null pointer.  As far as I know, no decently
written C program will break on this, and it would clean a lot of
cruft out of the language definition.

Dale

gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/16/87)

In article <1362@cullvax.UUCP> drw@cullvax.UUCP (Dale Worley) writes:
>What I propose is the NULL be made into a keyword of the language
>which acts like a constant and whose value is a pointer, and
>eliminating "0" as the null pointer.  As far as I know, no decently
>written C program will break on this, and it would clean a lot of
>cruft out of the language definition.

Although I agree with the intent, if 0 were not still guaranteed
to be equivalent to the null pointer, LOTS of existing applications
(for example, almost all of UNIX) would break.  Perhaps the best
approach would be to introduce NULL as a keyword, "deprecate" 0 for
null pointer (using other words, however), and hope that a future
revision of the C standard could remove the deprecated feature.
Unfortunately I suspect that you won't be able to persuade X3J11
that this is worth doing, but feel free to try.

throopw@xyzzy.UUCP (Wayne A. Throop) (07/29/87)

> gwyn@brl-smoke.ARPA (Doug Gwyn )
>> drw@cullvax.UUCP (Dale Worley)
>>What I propose is the NULL be made into a keyword of the language
>>which acts like a constant and whose value is a pointer, and
>>eliminating "0" as the null pointer.  As far as I know, no decently
>>written C program will break on this, and it would clean a lot of
>>cruft out of the language definition.

If by "decently written C program", you mean to exclude such things as

        { extern void f();
          f( NULL );
        }

(that is, passing this new keyword as a parameter to a function with no
prototype in scope), then I agree, but wonder where the benefit is?
Clearly, having a typeless NULL keyword will not help portability much,
since pointers of different types are potentially different sizes.

I guess it boils down to the facts that

        1) no decently written program will break on the use of 0 as a
           pointer constant now.
        2) I don't know of a case that is unsafe or nonportable with the
           use of 0 that would be made safe and portable by the use of
           a typeless pointer constant.

> Although I agree with the intent, if 0 were not still guaranteed
> to be equivalent to the null pointer, LOTS of existing applications
> (for example, almost all of UNIX) would break.  Perhaps the best
> approach would be to introduce NULL as a keyword, "deprecate" 0 for
> null pointer (using other words, however), and hope that a future
> revision of the C standard could remove the deprecated feature.
> Unfortunately I suspect that you won't be able to persuade X3J11
> that this is worth doing, but feel free to try.

Well, I agree that 0 must remain.  But I still don't see what the NULL
keyword buys you.  Or perhaps the light dawns: it would issue an error
diagnostic if used as a parameter with no prototype in scope, right?
There might be some small benefit to that, I suppose, but only for newly
minted code.  But for newly minted code, I'd druther kill more birds
with fewer stones by having an option to have the compiler issue a
diagnostic whenever there is no prototype in scope.  So I'm not
enthusiastic about NULL as a keyword.

--
"You have 15 seconds to comply."
        --- out-of-control robot, from RoboCop
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw

decot@hpisod2.HP.COM (Dave Decot) (07/29/87)

0 is currently not a null pointer constant of any type.

0 is an integer constant that can be assigned to any pointer variable,
or cast to any pointer type, producing a mysterious null pointer value
of the appropriate type.  0 can also be used to initialize pointer
variables to such a mysterious null pointer value.

Pointer-valued expressions can also be compared for equality or inequality
to the appropriate mysterious null pointer value by testing them against
the integer constant 0.

An integer 0 has no other appropriate usage in contexts where a pointer
value is ordinarily required; specifically, it is unusable as an actual
parameter in a function call unless transformed into the appropriate
mysterious null pointer value by a cast.

The language definition does not guarantee that the stored versions of
mysterious null pointer values for different pointer types have the same bit
pattern, or even that they are the same length.  It does not even guarantee
that two null pointers of the same type have the same bit pattern, although
they must appear to be equal when compared to each other and 0.

I see no real benefit to providing a NULL keyword in C, since 0 already
suffices.  If it is desired in ANSI C that 0 be automatically converted
to the appropriate null pointer value when used as an actual parameter
to a function with a prototype in scope, that's fine with me.

Dave Decot
hpda!decot

rob@amadeus.TEK.COM (Dan Tilque) (01/27/88)

It seems to me that several of the recent changes (parens honored, for
example) to the proposed standard are for the benefit of numerical programmers
and/or vector processors.  Most of the opposition seems to be coming from
systems programmers.  The systems people generally say: these are unnecessary;
if you want them, use FORTRAN.  The numerical programmers' answer is that C
produces much better code than FORTRAN.  (Or, in the case of noalias,
neither C nor FORTRAN has it but it's still not needed for most systems
work.)

My proposal is that we create a new language (perhaps called Cnum) in which
to put these type of features in.  As the name implies, Cnum would be C
oriented to numerical processing.  It would be upwardly compatable (more
or less) from K&R C.  It could also have an exponentiation operator and any
other features from FORTRAN which are deemed useful.  Then, when any of these
kinds of features are proposed in the future, we can all say: "Use Cnum".

It would probably be best to remove floats and doubles from C to further
emphasize the different uses of the two languages.  

Any comments?  Has this been done or proposed before?


---
Dan Tilque

This is a borrowed account, so be sure to indicate that replies are for me 
and not for Rob.

cik@l.cc.purdue.edu (Herman Rubin) (01/28/88)

In article <3057@zeus.TEK.COM>, rob@amadeus.TEK.COM (Dan Tilque) writes:

> It seems to me that several of the recent changes (parens honored, for
> example) to the proposed standard are for the benefit of numerical programmers
> and/or vector processors.  Most of the opposition seems to be coming from
> systems programmers.  The systems people generally say: these are unnecessary;
> if you want them, use FORTRAN.  The numerical programmers' answer is that C
> produces much better code than FORTRAN.  (Or, in the case of noalias,
> neither C nor FORTRAN has it but it's still not needed for most systems
> work.)
> 
> My proposal is that we create a new language (perhaps called Cnum) in which
> to put these type of features in.  

I find this far too restrictive.  I find it the case that C produces better
code than FORTRAN.  However, all too often I find that I have to introduce
assembler code into the C program.  Unfortunately, all of the C compilers
I have used do not allow the use of compiler-allocated locations in the
assembler code, and also use the atrocious assembler syntax.  

There are things that a compiler can do, and C does many of them reasonably
well, which should be made available to the programmer.  A compiler uses
temporaries, usually in registers, to store intermediate results.  The 
programmer may have to break down steps in a procedure for the compiler
to manage it; that results are of the type that the compiler uses for its
intermediates should be usable by the programmer.  There are machine 
instructions not understood by the language; we cannot have a language
which understands all possible machine instructions.  The programmer should
be able to say that the syntax of an instruction is like that of another,
in hardware only or in software only or both.  Unfortunately, the use of
overloaded operators is only available in compilers.  

It is not the case that FORTRAN or C is adequate for numerical mathematics.
There are great weaknesses in both.  There are portable operations, such as
frexp, which should not have portable code in the primitives of a language.
The code for &~ is not portable.  Whether one should use ++ or index depends
on the hardware.  The programmer should be able to introduce macros in any
notation, including infix, easily.  We need a flexible language, and C may
be the place to start.
> oriented to numerical processing.  It would be upwardly compatable (more
> or less) from K&R C.  It could also have an exponentiation operator and any
> other features from FORTRAN which are deemed useful.  Then, when any of these
> kinds of features are proposed in the future, we can all say: "Use Cnum".
> 
> It would probably be best to remove floats and doubles from C to further
> emphasize the different uses of the two languages.  
> 
> Any comments?  Has this been done or proposed before?
> 
> 
> ---
> Dan Tilque
> 
> This is a borrowed account, so be sure to indicate that replies are for me 
> and not for Rob.


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet

henry@utzoo.uucp (Henry Spencer) (02/02/88)

> It would probably be best to remove floats and doubles from C to further
> emphasize the different uses of the two languages.  

The graphics community, among others, will rise up and strangle you if you
try this.  No, it ISN'T just the number-crunchers who use floating point.
That silly misconception has doomed more than one programming language to
remaining an academic toy (or at least, has contributed to said fate).
-- 
Those who do not understand Unix are |  Henry Spencer @ U of Toronto Zoology
condemned to reinvent it, poorly.    | {allegra,ihnp4,decvax,utai}!utzoo!henry