Style (?) issue

D Yuniskis · 2011-01-03T09:50:07+00:00

Hi,(sigh) Another *@&^#($ night of "tree sitting". This getsold REALLY FAST! :-/Anyway, between trips outside, I've been dressing upsome old bits of software -- cleaning up commentary, etc.One of the things I do to help with debugging as well asmaking interfaces more explicit is to place DEBUG-onlyinvariants at the start of each function that "verify"the terms of the invocation contract. E.g., if a pointercan't be NULL, I'll do something like:ASSERT( (src != NULL), "Pointer to source must be non-NULL" );At run time, these go away (usually... depends on the marketI am serving). So, they don't "cost anything". And, theymake the interface rules *very* explicit (while thecommentary could possibly be ambiguous, the conditionalsin the invariants are hard to argue with!).So, the start of each function is usually a list of severalASSERT()'s -- at least one for each parameter (usually).Then, the meat of the function begins.One of the routines I was dressing up today had some constraintsplaced on a pointer passed to it. In particular, requiring thepointer to reference a valid memory location in a certainrange (defined by manifest constants).ONCE THROUGH THE INVARIANTS, "live code" would further qualifythe parameters passed to the routine. In this case, enforcingsome "arbitrary" alignment criteria. Conceivably, the alignedpointer could now reference something *outside* the range ofmemory locations enforced by the invariants. The code clearlyhas to test for this -- since the whole point is to ensurethose "out of bounds" areas are not referenced at run-time.Now, the nit pick... *technically*, the caller has compliedwith the contractual requirements of the function (the contractdoesn't enforce alignment issues -- that is part of the roleof the function itself). As such, I maintain that the originalset of invariants are *all* that should be enforced (todetermine if the invocation "complies"). The *further*,non-contractual alignment restriction that the function...

Jan 03, 2011 22 Replies

Rate this thread:

Cesar Rabak 15 years ago

[snipped]

More or less.

Yes, both values are potentially 'valid' as inputs to the downstream program, _but_ in this case the program verifier should be changed to insure the null pointer case is adequately treated and the program proceeds to a correct state, 'correct' in this case having two senses, the one the verifier can examine that a branch of the program treats this case, and in the application realm that the program/device does what is sensible and adequate to the business it serves.

[snipped]

Yes. In fact reducing the need for so many special code returns and so the space of possible failure modes is an art in itself!

Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/

Vote

Cesar Rabak 15 years ago

Em 4/1/2011 03:26, D Yuniskis escreveu: [snipped]

Humm... I think you need to think with more precision and have an accurate definition of terms.

An overflow is a _condition_ the program has reached. It can only be considered an error if in the specific application this leads to state which no useful progress of the program flow can be devised other than an 'error recovery' like asking the user to re-enter the numbers, etc.

Once you have a function that returns error codes, you have it!

Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/

Vote