assert must take int?

Discussion in 'C Programming' started by Tomás Ó hÉilidhe, Dec 8, 2007.

  1. In C89, do we have to pass an int as an argument to assert? I've got code
    at the moment that does an assertion on pointer, e.g.:

    assert(p);

    , but I'm wondering if I should change that to:

    assert(0 != p);


    --
    Tomás Ó hÉilidhe
    Tomás Ó hÉilidhe, Dec 8, 2007
    #1
    1. Advertising

  2. "Tomás Ó hÉilidhe" <> writes:

    > In C89, do we have to pass an int as an argument to assert? I've got code
    > at the moment that does an assertion on pointer, e.g.:
    >
    > assert(p);
    >
    > , but I'm wondering if I should change that to:
    >
    > assert(0 != p);


    Yes, in C89 the prototype is for an int. In C99 this has been changed
    to any scalar expression (of course you can't write that as a
    prototype but that is the implementation's problem, not yours).

    --
    Ben.
    Ben Bacarisse, Dec 8, 2007
    #2
    1. Advertising

  3. Richard Heathfield <> wrote in
    news::

    >> , but I'm wondering if I should change that to:
    >>
    >> assert(0 != p);

    >
    > Yes, you should (or use an equivalent such as assert(p != 0) or
    > assert(p != NULL) etc).




    Thanks for the info. I only came across the problem when I changed
    compilers recently, I got a boat-load of warnings about conversions from
    pointers to integer type :-O

    Looks like I'll be doing a "Find in files" for "assert" :p

    (I shudder to think what my previous compiler was actually doing... was it
    taking the pointer as a scalar or was it doing something... dirty... )


    --
    Tomás Ó hÉilidhe
    Tomás Ó hÉilidhe, Dec 8, 2007
    #3
  4. Tomás Ó hÉilidhe said:

    >
    > In C89, do we have to pass an int as an argument to assert? I've got code
    > at the moment that does an assertion on pointer, e.g.:
    >
    > assert(p);


    4.2.1.1 The assert macro

    Synopsis

    #include <assert.h>
    void assert(int expression);

    So you have to provide an int. If you don't, the behaviour is undefined.

    (As you seem to have guessed, in C99 this has changed, and the expression
    only has to be scalar - the restriction to int has been lifted.)

    >
    > , but I'm wondering if I should change that to:
    >
    > assert(0 != p);


    Yes, you should (or use an equivalent such as assert(p != 0) or assert(p !=
    NULL) etc).

    --
    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, Dec 8, 2007
    #4
  5. In article <Xns9A007F5B8DD68toelavabitcom@194.125.133.14>,
    Tomás Ó hÉilidhe <> wrote:
    >(I shudder to think what my previous compiler was actually doing... was it
    >taking the pointer as a scalar or was it doing something... dirty... )


    Your previous compiler was doing what most compilers have always done:
    define assert as a macro something like

    #define assert(e) \
    ((void) ((e) ? 0 : __assert (#e, __FILE__, __LINE__)))

    (that's the definition in MacOS X). The asserted expression is used
    as a conditional, so it works perfectly well with a pointer. That
    this is the Right Thing is confirmed by the change in C99.

    The restriction in C90 was clearly a mistake; I'm not sure where it
    came from.

    -- Richard
    --
    :wq
    Richard Tobin, Dec 8, 2007
    #5
  6. "Tom��������������������������������" wrote:
    > In C89, do we have to pass an int as an argument to assert?


    No, you need to pass an expression that yields a value of any integer
    type (and some implementations accept any scalar type, although that is
    not guaranteed).
    > I've got code
    > at the moment that does an assertion on pointer, e.g.:
    >
    > assert(p);


    Since pointers are not of an integer type, this is not a good idea.

    >
    > , but I'm wondering if I should change that to:
    >
    > assert(0 != p);


    That is probably a good idea.
    It is also a good idea to remember that the result of a failed assert
    can often be extreme consternation, puzzlement, and anger on the part of
    a user. Remember to define NDEBUG for any code outside of the testing
    stage, even if you consider using the assert macro a good debugging
    technique.
    Martin Ambuhl, Dec 8, 2007
    #6
  7. On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:
    > Tomás Ó hÉilidhe said:
    >> In C89, do we have to pass an int as an argument to assert? I've got
    >> code at the moment that does an assertion on pointer, e.g.:
    >>
    >> assert(p);

    >
    > 4.2.1.1 The assert macro
    >
    > Synopsis
    >
    > #include <assert.h>
    > void assert(int expression);
    >
    > So you have to provide an int. If you don't, the behaviour is undefined.


    The "prototype" would allow for an implicit conversion to int, if there
    isn't any statement suggesting otherwise, so it would mean that C90
    requires assert(0.5) to fail. It would also mean that assert(p); is a
    constraint violation, rather than undefined behaviour. Does C90 have
    relevant text on either of these points in what follows?
    Harald van Dijk, Dec 8, 2007
    #7
  8. Martin Ambuhl wrote:
    > "Tom��������������������������������" wrote:
    >> In C89, do we have to pass an int as an argument to assert?

    >
    > No, you need to pass an expression that yields a value of any integer
    > type (and some implementations accept any scalar type, although that is
    > not guaranteed).
    >> I've got code at the moment that does an assertion on pointer, e.g.:
    >>
    >> assert(p);

    >
    > Since pointers are not of an integer type, this is not a good idea.
    >
    >>
    >> , but I'm wondering if I should change that to:
    >>
    >> assert(0 != p);

    >
    > That is probably a good idea.
    > It is also a good idea to remember that the result of a failed assert
    > can often be extreme consternation, puzzlement, and anger on the part of
    > a user. Remember to define NDEBUG for any code outside of the testing
    > stage, even if you consider using the assert macro a good debugging
    > technique.


    Or perhaps rewriting it so it says something more like "Call 1-800-HELP-DESK and
    read us the rest of this message."
    Golden California Girls, Dec 8, 2007
    #8
  9. Tomás Ó hÉilidhe

    CJ Guest

    On 8 Dec 2007 at 12:31, Richard Heathfield wrote:
    > Tomás Ó hÉilidhe said:
    >
    >>
    >> In C89, do we have to pass an int as an argument to assert? I've got code
    >> at the moment that does an assertion on pointer, e.g.:
    >>
    >> assert(p);

    >
    > 4.2.1.1 The assert macro
    >
    > Synopsis
    >
    > #include <assert.h>
    > void assert(int expression);
    >
    > So you have to provide an int. If you don't, the behaviour is undefined.
    >
    > (As you seem to have guessed, in C99 this has changed, and the expression
    > only has to be scalar - the restriction to int has been lifted.)
    >
    >>
    >> , but I'm wondering if I should change that to:
    >>
    >> assert(0 != p);

    >
    > Yes, you should (or use an equivalent such as assert(p != 0) or assert(p !=
    > NULL) etc).


    But can't we get from the Standard the following two facts:
    1) any pointer can be converted (possibly with loss of information) to
    an int
    2) the value of such a converted pointer is 0 if and only if the pointer
    was NULL

    In this case all will be well - if there's a prototype in scope then the
    compiler will automatically convert the pointer to an int, and 2)
    guarantees that the assert behaves as intended.
    CJ, Dec 8, 2007
    #9
  10. Tomás Ó hÉilidhe

    pete Guest

    CJ wrote:

    > But can't we get from the Standard the following two facts:
    > 1) any pointer can be converted (possibly with loss of information) to
    > an int


    There's something like that in the standard.
    Either that, or the attempt can be undefined.

    N869
    6.3.2.3 Pointers
    [#6] Any pointer type may be converted to an integer type.
    Except as previously specified, the result is
    implementation-defined. If the result cannot be represented
    in the integer type, the behavior is undefined. The result
    need not be in the range of values of any integer type.

    > 2) the value of such a converted pointer
    > is 0 if and only if the pointer was NULL


    No.
    There's nothing like that in the standard.

    N869
    6.3.2.3 Pointers
    [#3] An integer constant expression with the value 0, or
    such an expression cast to type void *, is called a null
    pointer constant. If a null pointer constant is
    converted to a pointer type, the resulting pointer, called a
    null pointer, is guaranteed to compare unequal to a pointer
    to any object or function.


    --
    pete
    pete, Dec 8, 2007
    #10
  11. "Tomás Ó hÉilidhe" <> writes:
    > In C89, do we have to pass an int as an argument to assert? I've got code
    > at the moment that does an assertion on pointer, e.g.:
    >
    > assert(p);
    >
    > , but I'm wondering if I should change that to:
    >
    > assert(0 != p);


    Apart from the question of legality, remember that the text of the
    expression is printed as part of the error message. A message
    containing "p ~= NULL" is going to be much clearer than one containing
    just "p" (even if you use a clear name than "p").

    --
    Keith Thompson (The_Other_Keith) <>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 8, 2007
    #11
  12. In article <>,
    Keith Thompson <> wrote:

    >Apart from the question of legality, remember that the text of the
    >expression is printed as part of the error message. A message
    >containing "p ~= NULL" is going to be much clearer than one containing
    >just "p" (even if you use a clear name than "p").


    While this is true, I don't think the message is of much importance.
    Interpreting the output of an assertion failure is the programmer's
    job, and the first thing most programmers will do is look at the
    source code. Really the file and line number would be just as useful
    (who has multiple assert()s on a single line?).

    -- Richard
    --
    :wq
    Richard Tobin, Dec 8, 2007
    #12
  13. CJ wrote:


    > In this case all will be well - if there's a prototype in scope then the
    > compiler will automatically convert the pointer to an int, and 2)
    > guarantees that the assert behaves as intended.


    assert is defined by the standard to be a macro. There cannot be a
    prototype in scope.
    Martin Ambuhl, Dec 9, 2007
    #13
  14. [comp.lang.c] Keith Thompson <> wrote:

    > "Tom?s ? h?ilidhe" <> writes:


    >> assert(0 != p);


    I would personally prefer

    assert( NULL != p );

    , since the error message will be somewhat more descriptive,
    clarifying that p is a pointer that is NULL and not an integer that
    happened to be 0.

    > Apart from the question of legality, remember that the text of the
    > expression is printed as part of the error message. A message
    > containing "p ~= NULL" is going to be much clearer than one containing
    > just "p" (even if you use a clear name than "p").


    Hm, p ~= NULL sounds like a bad plan, but p != NULL might be ok :)

    --
    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, Dec 9, 2007
    #14
  15. [comp.lang.c] Richard Tobin <> wrote:

    (WRT assert()):

    > While this is true, I don't think the message is of much importance.
    > Interpreting the output of an assertion failure is the programmer's
    > job, and the first thing most programmers will do is look at the
    > source code. Really the file and line number would be just as useful
    > (who has multiple assert()s on a single line?).


    I initially intended to disagree with you, but given how assert is and
    more or less should be used, I can't make a strong argument for
    descriptive assert() messages other than mere aesthetics.

    --
    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, Dec 9, 2007
    #15
  16. Harald van D?k said:

    > On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:
    >>
    >> 4.2.1.1 The assert macro
    >>
    >> Synopsis
    >>
    >> #include <assert.h>
    >> void assert(int expression);
    >>
    >> So you have to provide an int. If you don't, the behaviour is undefined.

    >
    > The "prototype" would allow for an implicit conversion to int,


    Sure, but it isn't a prototype, is it? Yes, it don't 'arf look like one,
    but it's really a macro in disguise. Writing it in prototype form was,
    IMO, a mistake. So no, there is no implicit conversion to int.

    --
    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, Dec 9, 2007
    #16
  17. Golden California Girls said:

    > Martin Ambuhl wrote:
    >> It is also a good idea to remember that the result of a failed assert
    >> can often be extreme consternation, puzzlement, and anger on the part of
    >> a user. Remember to define NDEBUG for any code outside of the testing
    >> stage, even if you consider using the assert macro a good debugging
    >> technique.

    >
    > Or perhaps rewriting it so it says something more like "Call
    > 1-800-HELP-DESK and read us the rest of this message."


    I tried this, and got "the number you have dialled has not been
    recognised". Assuming we can fix that problem, some people will be using
    the program in situations where they can't use the phone (either because
    it's against the rules that apply in their place of work or simply because
    there isn't a phone immediately to hand), so the advice doesn't work for
    them.

    A failing assertion indicates a broken program. The proper solution is for
    your testers to have a complete list of assertions, and to arrange
    white-box tests that fire those assertions if it is at all possible. If
    they *can* fire the assertions, they reject the code. (And allow me to
    pre-empt at least one possible response by pointing out that I'm *not*
    claiming that's the *only* reason to reject code. But it is certainly one
    reason.)

    --
    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, Dec 9, 2007
    #17
  18. On 9 Dec, 07:35, Richard Heathfield <> wrote:
    > Golden California Girls said:


    > > Or perhaps rewriting it so it says something more like "Call
    > > 1-800-HELP-DESK and read us the rest of this message."

    >
    > I tried this, and got "the number you have dialled has not been
    > recognised". Assuming we can fix that problem, some people will be using
    > the program in situations where they can't use the phone (either because
    > it's against the rules that apply in their place of work or simply because
    > there isn't a phone immediately to hand), so the advice doesn't work for
    > them.


    Perhaps more importantly, the HELP-DESK people will likely
    just tell you to reboot and hope the problem doesn't
    reappear.
    William Pursell, Dec 9, 2007
    #18
  19. On Sun, 09 Dec 2007 07:29:08 +0000, Richard Heathfield wrote:
    > Harald van D?k said:
    >
    >> On Sat, 08 Dec 2007 12:31:35 +0000, Richard Heathfield wrote:
    >>>
    >>> 4.2.1.1 The assert macro
    >>>
    >>> Synopsis
    >>>
    >>> #include <assert.h>
    >>> void assert(int expression);
    >>>
    >>> So you have to provide an int. If you don't, the behaviour is
    >>> undefined.

    >>
    >> The "prototype" would allow for an implicit conversion to int,

    >
    > Sure, but it isn't a prototype, is it?


    If it's not a prototype, how does it require the expression to be an int?
    Harald van Dijk, Dec 9, 2007
    #19
  20. Tomás Ó hÉilidhe

    RoS Guest

    In data Sun, 9 Dec 2007 07:17:35 +0000 (UTC), Christopher
    Benson-Manica scrisse:
    >[comp.lang.c] Keith Thompson <> wrote:
    >
    >> "Tom?s ? h?ilidhe" <> writes:

    >
    >>> assert(0 != p);

    >
    >I would personally prefer
    >
    >assert( NULL != p );
    >
    >, since the error message will be somewhat more descriptive,
    >clarifying that p is a pointer that is NULL and not an integer that
    >happened to be 0.


    i disagree
    i cancelled all NULLs because the C[++?] compiler not compiled
    some one of these (don't know why)

    than i thought that with only one "0" the language were more easy;
    for me exist only "0"; no NULL no '\0' no NUL

    >> Apart from the question of legality, remember that the text of the
    >> expression is printed as part of the error message. A message
    >> containing "p ~= NULL" is going to be much clearer than one containing
    >> just "p" (even if you use a clear name than "p").

    >
    >Hm, p ~= NULL sounds like a bad plan, but p != NULL might be ok :)
    RoS, Dec 9, 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. Schnoffos
    Replies:
    2
    Views:
    1,188
    Martien Verbruggen
    Jun 27, 2003
  2. Hal Styli
    Replies:
    14
    Views:
    1,604
    Old Wolf
    Jan 20, 2004
  3. Robert Brewer
    Replies:
    1
    Views:
    468
    bsmith
    Nov 7, 2004
  4. Thomas Guettler

    assert 0, "foo" vs. assert(0, "foo")

    Thomas Guettler, Feb 23, 2005, in forum: Python
    Replies:
    3
    Views:
    2,484
    Carl Banks
    Feb 23, 2005
  5. Alex Vinokur

    assert(x) and '#define ASSERT(x) assert(x)'

    Alex Vinokur, Nov 25, 2004, in forum: C Programming
    Replies:
    5
    Views:
    880
    Keith Thompson
    Nov 25, 2004
Loading...

Share This Page