Assertion before definitions

[Frederick Gotham]

What's the canonical way to perform an assertion before the definition of any
objects within a function? I've got this at the moment:

void AddFiveEachElement(int *p,size_t const len)
{
int dummy = (assert(p),assert(len),0);

int const *const pover = p + len;

/* Let's pretend we initialise an array here:

int array[4] = {p[0],p[1],p[2],p[3]};
*/

do
{
*p++ = 5;
}while(pover != p);
}

 

[SM Ryan]

#
# What's the canonical way to perform an assertion before the definition of any
# objects within a function? I've got this at the moment:

With modern C compilers, you can intermingle statements and
declarations

# {
# assert(p); assert(len);
# int const *const pover = p + len;
# /* Let's pretend we initialise an array here:
# int array[4] = {p[0],p[1],p[2],p[3]};
# */
# do
# {
# *p++ = 5;
# }while(pover != p);
# }

On older C compilers, you can insert additional {...}

# {
# assert(p); assert(len); {
# int const *const pover = p + len;
# /* Let's pretend we initialise an array here:
# int array[4] = {p[0],p[1],p[2],p[3]};
# */
# do
# {
# *p++ = 5;
# }while(pover != p);
# }}

 

[Peter Nilsson]

What's the canonical way to perform an assertion before the definition of any
objects within a function?

Use C99?

But there isn't one for C90 that I know of. If you want a genuine
debugging tool
you'll either use a serious debugger, or roll your own suite of more
useful tools.

I've got this at the moment:

void AddFiveEachElement(int *p,size_t const len)
{
int dummy = (assert(p),assert(len),0);

Note that assert() on C90 requires an int argument, so you should make
your assertions more explicit.

int const *const pover = p + len;

/* Let's pretend we initialise an array here:
int array[4] = {p[0],p[1],p[2],p[3]};

Just as well you're only pretending. ;-)

*/

do
{
*p++ = 5;
}while(pover != p);
}

One simple way is...

void foo(int *p,size_t len)
{
assert(p != NULL);
assert(len != 0);
{
/* ze code */
}
}

But performing exit checks in non-void functions makes it even uglier.

 

[Bill Pursell]

What's the canonical way to perform an assertion before the definition of any
objects within a function? I've got this at the moment:

void AddFiveEachElement(int *p,size_t const len)
{
int dummy = (assert(p),assert(len),0);

int const *const pover = p + len;

{
int * const pover = p+len;
assert(p != NULL && len > 0);
...


The only risk is if the arithmetic or the assignment
cause undefined behavior. (eg int *const pover = p[5]) would
be bad.) In this case, the addition is valid regardless of
the values of p and len, so there's no risk. Even if
you have a case where there is risk, I think it's acceptable
to write it this way, since the assertion is only being
used as a clue to the human reader. I suppose that if
the assignment invokes undefined
behavior that makes the assertions not abort
in the normal fashion, it might cause some trouble
tracking down the error.

 

[Flash Gordon]

What's the canonical way to perform an assertion before the definition of any
objects within a function? I've got this at the moment:

void AddFiveEachElement(int *p,size_t const len)
{
int dummy = (assert(p),assert(len),0);

int const *const pover = p + len;

{
int * const pover = p+len;
assert(p != NULL && len > 0);
...


The only risk is if the arithmetic or the assignment
cause undefined behavior. (eg int *const pover = p[5]) would
be bad.) In this case, the addition is valid regardless of
the values of p and len, so there's no risk.

No it is not valid for all values of p and len. Pointer arithmetic is
only defined within an object and one past the end of the original
object. Since the null pointer does not point to an object (that is a
major point of it) *any* arithmetic with a null pointer is undefined
through the lack of a definition. If p points to a valid object and
p+len takes you more that one past the end of the object that again you
have undefined behaviour.

> Even if
you have a case where there is risk, I think it's acceptable
to write it this way, since the assertion is only being
used as a clue to the human reader. I suppose that if
the assignment invokes undefined
behavior that makes the assertions not abort
in the normal fashion, it might cause some trouble
tracking down the error.

Or the assignment having invoked undefined behaviour could cause the
program to ignore the assert and continue to crash later. How the
implementation could achieve this I'm not sure, but a sufficiently
perverse implementation is certainly allowed to.

So why not avoid the undefined behaviour the assert is intended to catch
by doing the assert first to it is ensured for of the chance to do its job.

 

[Bill Pursell]

So why not avoid the undefined behaviour the assert is intended to catch
by doing the assert first to it is ensured for of the chance to do its job.

How do you do that
without using C90 syntax and allowing declarations to be
mixed with code? eg, you can't do:

int *const p;
assert( f != NULL);
p = f + l; <-- invalid write to read-only p

So you must instead do:
assert(f != NULL);
int *const p = f+l;

Or do as Frederick did in the original post, something like:
int a = (assert(f != NULL), 0);
int *const p = f + l;

Personally, I think that's pretty ugly. It's a little bit better to
group it with the assignment: eg

int *const p = (assert(f!=NULL), f+l);

 

[Flash Gordon]

How do you do that
without using C90 syntax and allowing declarations to be
mixed with code? eg, you can't do:

int *const p;
assert( f != NULL);
p = f + l; <-- invalid write to read-only p

So you must instead do:
assert(f != NULL);
int *const p = f+l;

Or if the function is short enough to check by inspection
int *p; /* Note to maintainer, this should never be modified after
initial assignment */
assert( f != NULL);
p = f + l;

Not ideal.

Or do as Frederick did in the original post, something like:
int a = (assert(f != NULL), 0);
int *const p = f + l;

Personally, I think that's pretty ugly. It's a little bit better to
group it with the assignment: eg

int *const p = (assert(f!=NULL), f+l);

Or as has also been suggested introducing another scope.

None of them are ideal, but they all have the advantage of doing the
check before invoking undefined behaviour so ensuring that it will work
properly rather than relying on the properties of the system.

Personally I will allow a little ugliness for the sake of portability.
However, once it is accepted that there is undefined behaviour it is up
to the people in question to decide on whether for them it is worth
loosing some potential portability for the sake of better looking code
or not. Not everything has to be portable to all possible systems after
all and this is a check to catch program errors during development
rather than in release code where with NDEBUG defined the assert won't
do anything anyway.

 

[Chris Torek]

Right -- but this uses C99 features (specifically, "variable
declaration/definition almost anywhere", or at least "after
code and without intervening open-brace").

Or if the function is short enough to check by inspection
int *p; /* Note to maintainer, this should never be modified after
initial assignment */
assert( f != NULL);
p = f + l;

Not ideal.

Maybe not ideal, but probably what I would do. Of course, I always
thought that "const" *should* have been defined as a storage-class
specifier (with appropriate modifications to the syntax and semantics
so that you can apply it as well as, e.g., "static"), rather than
a type-qualifier. So my opinion may be suspect.

I can definitely go for this one.

Or as has also been suggested introducing another scope.

Note that you can even do this by introducing an entire separate
function, e.g.:

void operate_unchecked(T *ptr, size_t len) {
... all the "real work" goes here ...
}

void operate(T *ptr, size_t len) {
/* this is not an assert() because it is delivered in the
final version of the product! */
if (ptr == NULL || len == 0)
panic("bad arguments to operate()");
operate_unchecked(ptr, len);
}

Depending on performance goals and profiling, "operate_unchecked"
can initially be static (and, in C99, explicitly "inline" if you
like), and later exposed (if performance testing proves that the
parameter-checking is a significant performance problem).