Nullable/Notnull : syntax proposal

[sarnold]

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.

Regards,
Stéphane A.

[Richard]

Eric Sosman <es*****@ieee-dot-org.invalidwrit es:

sa*****@free.fr 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.

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

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.

[jacob navia]

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
occasionall y (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

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

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
occasional ly (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.

[Stephen Sprunk]

<sa*****@free.f rwrote in message
news:11******** **************@ d55g2000hsg.goo glegroups.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

[Christopher Benson-Manica]

[comp.lang.c] Eric Sosman <es*****@ieee-dot-org.invalidwrot e:

sa*****@free.fr 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)gma il.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.or g | Google groups, due to rampant unchecked spam.

[Eric Sosman]

Christopher Benson-Manica wrote On 11/06/07 11:07,:

[comp.lang.c] Eric Sosman <es*****@ieee-dot-org.invalidwrot e:

>>sa*****@free. fr 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.

--
Er*********@sun .com

[Richard Heathfield]

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

[Mark McIntyre]

On Tue, 06 Nov 2007 12:15:22 -0500, in comp.lang.c , Eric Sosman
<Er*********@su n.comwrote:

>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

[Christopher Benson-Manica]

[comp.lang.c] Eric Sosman <Er*********@su n.comwrote:

Christopher Benson-Manica wrote On 11/06/07 11:07,:

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

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.

You're right - sorry. <ot>The Java IDE I use (IntelliJ IDEA)
suggests initializing variables in this fashion, a habit that has
merits and drawbacks, but in any case doesn't really fit the C
paradigm.</ot It wasn't the best example.

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.

malloc() might not be a good example, since its behavior is
standardized and well-known to all with access to a man page. OTOH
user functions (possibly written by other developers) don't enjoy that
luxury, and might profitably be "annotated" (to borrow a term) to
return "NULLable" or "not NULL".

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.

I agree (as I alluded to in my last paragraph). It seems to me that
implementations would have to retain the right to ignore such
assertion suggestions (much as they retain the right to ignore the
register keyword), and in any case I don't believe that such additions
to C would provide the benefits that they do in other langusages.

--
C. Benson Manica | I appreciate all corrections, polite or otherwise.
cbmanica(at)gma il.com |
----------------------| I do not currently read any posts posted through
sdf.lonestar.or g | Google groups, due to rampant unchecked spam.