Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Nullable/Notnull : syntax proposal

Reply
Thread Tools

Nullable/Notnull : syntax proposal

 
 
Eric Sosman
Guest
Posts: n/a
 
      11-05-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hello,
>
> I am proposing to create two new keywords for C, 'notnull' and
> 'nullable'.
> Their meaning is a sort of 'design by contract', ensuring some rules
> are
> verified at compile-time. It should not require additional runtime-
> checks
> to be implemented.
> I have posted my description of how it should work at this URL:
> http://sarnold.free.fr/wordpress/?p=71
> Please read it and tell me what you think of it.


Your proposal should describe why the proposed feature
would be useful, why it would make life better for programmers
and/or improve the quality of programs. If the information
is already there, it is presented too subtly for me to grasp.

By the way, the example with free() is not well-chosen.
The behavior of free() with a NULL argument is well-defined;
there is no need to assert that the argument cannot be NULL,
because it can be. Perhaps an example with fclose() or
strlen() would raise fewer eyebrows.

--
Eric Sosman
(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      11-05-2007
Eric Sosman <(E-Mail Removed)> writes:

> (E-Mail Removed) wrote:
>> Hello,
>>
>> I am proposing to create two new keywords for C, 'notnull' and
>> 'nullable'.
>> Their meaning is a sort of 'design by contract', ensuring some rules
>> are
>> verified at compile-time. It should not require additional runtime-
>> checks
>> to be implemented.
>> I have posted my description of how it should work at this URL:
>> http://sarnold.free.fr/wordpress/?p=71
>> Please read it and tell me what you think of it.

>
> Your proposal should describe why the proposed feature
> would be useful, why it would make life better for programmers
> and/or improve the quality of programs. If the information
> is already there, it is presented too subtly for me to grasp.


It is pretty obvious what "notnull" means. But as I said in a previous
post if the use is limited to allocation assignments better to do the
checks and relevant dumps in the allocation functions themselves.

>
> By the way, the example with free() is not well-chosen.
> The behavior of free() with a NULL argument is well-defined;
> there is no need to assert that the argument cannot be NULL,
> because it can be. Perhaps an example with fclose() or
> strlen() would raise fewer eyebrows.

 
Reply With Quote
 
 
 
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      11-05-2007
On Sun, 04 Nov 2007 20:12:30 +0100, jacob navia wrote:
> Harald van Dijk wrote:
>> On Sun, 04 Nov 2007 18:53:49 +0100, jacob navia wrote:
>>> You can assert a parameter not being null in standard C by
>>>
>>> int function(int MyTable[static 1]);

>>
>> Almost, but not quite.
>>
>>> This means that the parameter MyTable has at least one element, i.e.
>>> it can't be NULL.

>>
>> It means you can't call function with the result of malloc(1), while
>> occasionally (okay, rarely) that's actually useful.

>
> Can you explain what you say?
>
> I didn't understand what you are saying.


Assuming sizeof(int) > 1, and some free memory, malloc(1) is a non-null
pointer that doesn't point to at least one int. So if you pass that
pointer to a function defined as taking int[static 1], the behaviour is
undefined. If you could specify a function as needing a non-null pointer,
it would (presumably) be allowed, since it is a valid pointer which is not
a null pointer.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-05-2007
Harald van Dijk wrote:
> On Sun, 04 Nov 2007 20:12:30 +0100, jacob navia wrote:
>> Harald van Dijk wrote:
>>> On Sun, 04 Nov 2007 18:53:49 +0100, jacob navia wrote:
>>>> You can assert a parameter not being null in standard C by
>>>>
>>>> int function(int MyTable[static 1]);
>>> Almost, but not quite.
>>>
>>>> This means that the parameter MyTable has at least one element, i.e.
>>>> it can't be NULL.
>>> It means you can't call function with the result of malloc(1), while
>>> occasionally (okay, rarely) that's actually useful.

>> Can you explain what you say?
>>
>> I didn't understand what you are saying.

>
> Assuming sizeof(int) > 1, and some free memory, malloc(1) is a non-null
> pointer that doesn't point to at least one int. So if you pass that
> pointer to a function defined as taking int[static 1], the behaviour is
> undefined. If you could specify a function as needing a non-null pointer,
> it would (presumably) be allowed, since it is a valid pointer which is not
> a null pointer.


I think the "static 1" means that you have AT LEAST 1 int (in this case)

This means that passing a pointer to a buffer less than sizeof(int)
is illegal. Of course you can pass a non null pointer to a wrong
buffer but the interface requirements mean that the pointer points
to a buffer AT LEAST bigger than sizeof(int).



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0Fk?=
Guest
Posts: n/a
 
      11-05-2007
On Mon, 05 Nov 2007 19:54:40 +0100, jacob navia wrote:
> Harald van Dijk wrote:
>> On Sun, 04 Nov 2007 20:12:30 +0100, jacob navia wrote:
>>> Harald van Dijk wrote:
>>>> On Sun, 04 Nov 2007 18:53:49 +0100, jacob navia wrote:
>>>>> You can assert a parameter not being null in standard C by
>>>>>
>>>>> int function(int MyTable[static 1]);
>>>> Almost, but not quite.
>>>>
>>>>> This means that the parameter MyTable has at least one element, i.e.
>>>>> it can't be NULL.
>>>> It means you can't call function with the result of malloc(1), while
>>>> occasionally (okay, rarely) that's actually useful.
>>> Can you explain what you say?
>>>
>>> I didn't understand what you are saying.

>>
>> Assuming sizeof(int) > 1, and some free memory, malloc(1) is a non-null
>> pointer that doesn't point to at least one int. So if you pass that
>> pointer to a function defined as taking int[static 1], the behaviour is
>> undefined. If you could specify a function as needing a non-null
>> pointer, it would (presumably) be allowed, since it is a valid pointer
>> which is not a null pointer.

>
> I think the "static 1" means that you have AT LEAST 1 int (in this case)


Exactly.

> This means that passing a pointer to a buffer less than sizeof(int) is
> illegal.


Exactly.

> Of course you can pass a non null pointer to a wrong buffer but
> the interface requirements mean that the pointer points to a buffer AT
> LEAST bigger than sizeof(int).


Which means int[static 1] is a stronger requirement than what
int *nonnull would mean if nonnull existed as a keyword.
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      11-06-2007
<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> I am proposing to create two new keywords for C, 'notnull' and
> 'nullable'.
> Their meaning is a sort of 'design by contract', ensuring some rules
> are verified at compile-time. It should not require additional runtime-
> checks to be implemented.


I don't see the point if there's no runtime checking. A compile-time check
could only flag cases where a pointer _might_ be null, but any pointer
_might_ be null if you don't know where it came from.

For this to be useful, you'd need to do the checks at runtime; that
basically boils down to the compiler inserting an assert() for the
programmer either before each assignment and either before each function
call or after each function entry. If I wanted that (and I almost always
do), I'd put the necessary assert()s in myself, or use some sort of if/else
logic for more friendly results.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking


--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      11-06-2007
[comp.lang.c] Eric Sosman <(E-Mail Removed)> wrote:

> (E-Mail Removed) wrote:
>> I am proposing to create two new keywords for C, 'notnull' and
>> 'nullable'.


> Your proposal should describe why the proposed feature
> would be useful, why it would make life better for programmers
> and/or improve the quality of programs. If the information
> is already there, it is presented too subtly for me to grasp.


<topicality level="dubious">

I may be mistaken, but I suspect that OP's motivation for proposing
this change stems from the @NotNull and @Nullable annotations provided
by certain Java IDE's. Within the context of an IDE, the "nullable"
and "notnull" keywords could have significant value, as the IDE could
warn you prior to compilation that

void foo( notnull void *bar ) {
/* ... */
}

void baz() {
void *qux = NULL;
/* Oops, forgot to initialize pointer */
foo( qux );
}

probably represents an error. It seems to me that it would be
slightly less distasteful to the Committee to propose an annotation
mechanism similar to Java's, where an annotation (possibly in the Java
style) could be prepended to any variable or definition, where the
meaning of any such annotation would be implementation-defined.

That said, Java and C are generally (IMVHO) developed in
different styles - Java developers are much more likely to develop
using IDE's that can benefit from such annotations than C developers
(if indeed there are any IDE's for C of that level of sophistication).
I don't see a lot of use in a language change which would
realistically only benefit a small subset of C programmers.

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gmail.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.org | Google groups, due to rampant unchecked spam.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      11-06-2007
Christopher Benson-Manica wrote On 11/06/07 11:07,:
> [comp.lang.c] Eric Sosman <(E-Mail Removed)> wrote:
>
>
>>(E-Mail Removed) wrote:
>>
>>>I am proposing to create two new keywords for C, 'notnull' and
>>>'nullable'.

>
>
>> Your proposal should describe why the proposed feature
>>would be useful, why it would make life better for programmers
>>and/or improve the quality of programs. If the information
>>is already there, it is presented too subtly for me to grasp.

>
>
> <topicality level="dubious">
>
> I may be mistaken, but I suspect that OP's motivation for proposing
> this change stems from the @NotNull and @Nullable annotations provided
> by certain Java IDE's. Within the context of an IDE, the "nullable"
> and "notnull" keywords could have significant value, as the IDE could
> warn you prior to compilation that
>
> void foo( notnull void *bar ) {
> /* ... */
> }
>
> void baz() {
> void *qux = NULL;
> /* Oops, forgot to initialize pointer */
> foo( qux );
> }
>
> probably represents an error. [...]


Maybe I'm just being dense today (or this year, or
this life), but I still don't get it. Drop the silly
initialization, and a good compiler will *already* warn
about the probable error -- and not just for pointers,
either.

As far as I can see, the only "use case" is for
variations on

char *p = malloc(strlen(s) + 1);
/* no NULL check here */
strcpy (p, s);

This is a class of error I can't recall having made (I
make others instead), so I'm not especially attracted by
machinery that helps me solve a problem I don't have.

A way to make assertions about values might be a
useful thing, but I think it should be in a more general
framework than just NULL-or-not.

--
(E-Mail Removed)
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      11-06-2007
Christopher Benson-Manica said:

<snip>

> void baz() {
> void *qux = NULL;
> /* Oops, forgot to initialize pointer */


Wrong. qux has in fact been initialised.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      11-06-2007
On Tue, 06 Nov 2007 12:15:22 -0500, in comp.lang.c , Eric Sosman
<(E-Mail Removed)> wrote:

>Drop the silly
>initialization, and a good compiler will *already* warn
>about the probable error -- and not just for pointers,
>either.

Mind you, a compiler has no obligation to warn, and additionally
warnings can be ignored by the programmer / build engine, especially
when your code is packed with spurious warnings generated from your
implementation's headers. OTOH the OP's suggestion seems to be
intended to generate a fatal error message?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python dot-equals (syntax proposal) Jabapyth Python 40 05-03-2010 05:15 PM
multiple return values (new syntax proposal) aleksandar.ristovski@gmail.com C++ 8 09-10-2006 01:05 AM
IL Generator syntax proposal John Lam Ruby 8 12-07-2005 12:56 AM
RE: pre-PEP: Suite-Based Keywords - syntax proposal Robert Brewer Python 13 04-20-2005 06:21 PM
PEP-318, billion-and-first syntax proposal Tim Hochberg Python 0 08-10-2004 07:38 PM



Advertisments