Nullable/Notnull : syntax proposal

Discussion in 'C Programming' started by sarnold@free.fr, Nov 4, 2007.

  1. Guest

    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.
     
    , Nov 4, 2007
    #1
    1. Advertising

  2. Richard Guest

    writes:

    > 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.


    Simplify it. There is no need for "nullable" since it's already there.

    In addition I think it's a silly idea. Just wrap malloc to do what you want to
    do rather than have the assignment to a notnull variable. Much more
    efficient. Otherwise every time you assign to a notnull the system will
    be performing these checks.
     
    Richard, Nov 4, 2007
    #2
    1. Advertising

  3. Ben Pfaff Guest

    writes:

    > I am proposing to create two new keywords for C, 'notnull' and
    > 'nullable'.


    How does this relate to the GCC extension that provides for a
    "nonnull" attribute on function arguments? Here is the
    documentation for the GCC extension:

    `nonnull (ARG-INDEX, ...)'
    The `nonnull' attribute specifies that some function parameters
    should be non-null pointers. For instance, the declaration:

    extern void *
    my_memcpy (void *dest, const void *src, size_t len)
    __attribute__((nonnull (1, 2)));

    causes the compiler to check that, in calls to `my_memcpy',
    arguments DEST and SRC are non-null. If the compiler determines
    that a null pointer is passed in an argument slot marked as
    non-null, and the `-Wnonnull' option is enabled, a warning is
    issued. The compiler may also choose to make optimizations based
    on the knowledge that certain function arguments will not be null.

    If no argument index list is given to the `nonnull' attribute, all
    pointer arguments are marked as non-null. To illustrate, the
    following declaration is equivalent to the previous example:

    extern void *
    my_memcpy (void *dest, const void *src, size_t len)
    __attribute__((nonnull));

    By the way, comp.std.c would be a better place to discuss this.
    Followups set.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
     
    Ben Pfaff, Nov 4, 2007
    #3
  4. pete Guest

    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.


    I don't need it.
    I don't want it.
    I don't like it.
    I'm surprised it isn't already in C99.

    --
    pete
     
    pete, Nov 4, 2007
    #4
  5. jacob navia Guest

    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.
    >
    > Regards,
    > Stéphane A.
    >


    You can assert a parameter not being null in standard C by

    int function(int MyTable[static 1]);

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

    True, it is NOT a GREAT syntax but it is standard.

    jacob
     
    jacob navia, Nov 4, 2007
    #5
  6. santosh Guest

    wrote:

    > I am proposing to create two new keywords for C, [ ... ]


    Since you are apparently proposing changes to the language the correct
    group for that would be <news:comp.std.c>
     
    santosh, Nov 4, 2007
    #6
  7. Richard Guest

    santosh <> writes:

    > wrote:
    >
    >> I am proposing to create two new keywords for C, [ ... ]

    >
    > Since you are apparently proposing changes to the language the correct
    > group for that would be <news:comp.std.c>


    He is asking for C programmer's opinions. So here is perfectly valid.
     
    Richard, Nov 4, 2007
    #7
  8. On Sun, 04 Nov 2007 18:53:49 +0100, jacob navia wrote:
    > 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.
    >>
    >> Regards,
    >> Stéphane A.
    >>
    >>

    > 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.
     
    =?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F, Nov 4, 2007
    #8
  9. jacob navia Guest

    Harald van Dijk wrote:
    > On Sun, 04 Nov 2007 18:53:49 +0100, jacob navia wrote:
    >> 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.
    >>>
    >>> Regards,
    >>> Stéphane A.
    >>>
    >>>

    >> 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.
     
    jacob navia, Nov 4, 2007
    #9
  10. Jack Klein Guest

    On Sun, 04 Nov 2007 09:23:20 -0800, wrote in
    comp.lang.c:

    > 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.


    No. Because...no.

    Not even if you made them _Notnull and _Nullable, which I'm fairly
    sure the committee would insist on to keep them in the implementation
    namespace to avoid breaking existing code.

    Just no.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Nov 5, 2007
    #10
  11. Eric Sosman Guest

    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
    lid
     
    Eric Sosman, Nov 5, 2007
    #11
  12. Richard Guest

    Eric Sosman <> writes:

    > 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.
     
    Richard, Nov 5, 2007
    #12
  13. 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.
     
    =?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F, Nov 5, 2007
    #13
  14. jacob navia Guest

    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
     
    jacob navia, Nov 5, 2007
    #14
  15. 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.
     
    =?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F, Nov 5, 2007
    #15
  16. <> wrote in message
    news:...
    > 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
     
    Stephen Sprunk, Nov 6, 2007
    #16
  17. [comp.lang.c] Eric Sosman <> wrote:

    > 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.
     
    Christopher Benson-Manica, Nov 6, 2007
    #17
  18. Eric Sosman Guest

    Christopher Benson-Manica wrote On 11/06/07 11:07,:
    > [comp.lang.c] Eric Sosman <> wrote:
    >
    >
    >> 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.

    --
     
    Eric Sosman, Nov 6, 2007
    #18
  19. 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
     
    Richard Heathfield, Nov 6, 2007
    #19
  20. On Tue, 06 Nov 2007 12:15:22 -0500, in comp.lang.c , Eric Sosman
    <> 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
     
    Mark McIntyre, Nov 6, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. buran

    nullable sqlparameter

    buran, Jul 17, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    517
    buran
    Jul 17, 2003
  2. Kevin Yu

    DateTime not nullable problem

    Kevin Yu, Jan 28, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    7,640
    MWells
    Jan 29, 2005
  3. Jacques Wentworth

    Property 'Keycode' is non-nullable

    Jacques Wentworth, Mar 11, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    3,620
    Jacques Wentworth
    Mar 11, 2005
  4. Child

    Nullable DateTime variables

    Child, May 3, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    24,598
    elizas
    May 7, 2010
  5. Mark Rae

    Nullable strings as parameters

    Mark Rae, Jan 25, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    21,417
    Mark Rae
    Jan 25, 2006
Loading...

Share This Page