reverse a string

[Phil Carmody]

In the real world, users tend not to enjoy broken code very much,
True.

and will try to avoid vendors who ship it to them.

Unproven, and suspected false.

Phil

 

[Phil Carmody]

I have just completed a statistical study in which 100% of users said
they no longer buy products from companies from whom they have bought
buggy products in the past. (Sample size: 1!)

Sample size 3. And we all agree. But I still suspect I'm in a minority.

Phil

 

[osmium]

I have just completed a statistical study in which 100% of users said
they no longer buy products from companies from whom they have bought
buggy products in the past. (Sample size: 1!)

You are a master of careful wording! From your posts, I am sure you have
acquired (not necessarily bought) Microsoft products in the past, but your
post is bulletproof.

 

[Mark]

The general idea is that assert() should check for logic errors in
the program. If you find that you need to store N things, malloc() an
N-place array to hold them, and start filling array[j] in a loop that
increments j, you might assert(j < N) before trying to use the index,
and you might assert(j == N) at the end -- both would amount to checks
that you calculated N correctly to begin with.

Ok, so we might have something like this:

#define N 20
int i;
char *ptr = malloc(N);

for (i = 0; i < N; i++)
{
ptr = 'x';
}
free(ptr);

How can 'assert(j < N)' or 'assert(j == N)' help if these checks are in fact
done in a 'for' loop? Or you referred to a different example?

 

[Richard Bos]

Phase 1 of defensive programming is knowing when to insert assert()s.
Phase 2 of defensive programming is knowing when to not insert them.

Use asserts only for situations which show a logical inconsistency,
not things that you don't want to happen, or things that mustn't happen,
but things that cannot, with working code, ever logically happen.

And it's important here to distinguish between code that does things
that it cannot logically do, and data that contains things it cannot
logically contain. For the former, you want assert(), and not ever let
your user see such ugliness. For the latter, you want a much more user-
friendly error reporting mechanism which poor ickle luser's poor ickle
brain can understand enough of to remedy the situation himself.

Richard

 

[Richard Bos]

Unproven, and suspected false.

_Proven_ false - which company sells the most software?

But even in the real world, an assert() is useless in the face of a
normal user. A proper assertion which writes a comprehensive log entry
and puts up a non-programmer-understandable message box on the screen,
yes, that may (_may_, mind you!) be of use. But an assert() which
flashes up a console window which disappears before the user knows that
anything happened, let alone what, and which prints a message to that
window which said user would, in any case, not in a dozen blue moons
have communicated back to the programmer in a remotely useful form?
Forget it. Dike it out.

Richard

 

[Herbert Rosenau]

Could you guys explain me *when* one should use 'assert'. I do understand
what it does and I have read c-FAQ 20.24b, but consider the code proposed by
user923005 earlier:

assert() uis there for brainless programmers to save theyr brain. In
more than 25years programming I found no sense for assert.

assert evaluates to a NOOP when compiling NOT in debug mode, so it
does nothing in produnction code.

assert in debug mode makes no sense because when you as writer of the
code does a check against your dumbness you have found the bug already
but too dumb to resolve it.

assert is not designed to make a test against data - it can only
defend against the dumbness of the programmer that writes the assert,
it can't defend against dumbness the user using the program.

So assert is at least completely useless.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Ben Bacarisse]

assert() uis there for brainless programmers to save theyr brain. In
more than 25years programming I found no sense for assert.

assert evaluates to a NOOP when compiling NOT in debug mode, so it
does nothing in produnction code.

assert in debug mode makes no sense because when you as writer of the
code does a check against your dumbness you have found the bug already
but too dumb to resolve it.

That does not seem logical to me. A program that fails an assert
simply has a bug in it. There is no reason to conclude that the
author is too dumb to fix the bug.

You are correct that a failed assert is sign of dumbness, but as a
dumb programmer I find it very useful. Despite being dumb enough to
write programs with bugs, I have been un-dumb enough to fix them
all eventually -- often within seconds.

So assert is at least completely useless.

You are lucky and, presumably, very careful and not at all dumb (I
don't know what the opposite of dumb is). Presumably you also never
work with anyone else who does not match up or you'd find assert
useful in that sort of situation as well.

 

[Keith Thompson]

assert() uis there for brainless programmers to save theyr brain. In
more than 25years programming I found no sense for assert.

assert evaluates to a NOOP when compiling NOT in debug mode, so it
does nothing in produnction code.

assert in debug mode makes no sense because when you as writer of the
code does a check against your dumbness you have found the bug already
but too dumb to resolve it.

assert is not designed to make a test against data - it can only
defend against the dumbness of the programmer that writes the assert,
it can't defend against dumbness the user using the program.

So assert is at least completely useless.

Many programmers find assert to be quite useful. It's sometimes much
easier to define a condition that must be true if the code is correct
than to prove that the code actually satisfies the condition.

It does not (necessarily) defend against the "dumbness" of the
programmer. It defends against mistakes by the programmer.
Perhaps you never make mistakes, but most of us do.

I suggest you try to understand it before you claim that it, and
programmers who use it, are stupid.

 

[Richard Tobin]

assert in debug mode makes no sense because when you as writer of the
code does a check against your dumbness you have found the bug already
but too dumb to resolve it.

I can't make much sense of that sentence.

When I use assert() it's not usually because I have found a bug, but
to alert me to the presence of bugs which might exist elsewhere in the
code.

My use of assert() has on many occasions made debugging easier, and in
some cases has shown up bugs that might have gone undetected, leading
to incorrect results.

-- Richard

 

[user923005]

Many programmers find assert to be quite useful.  It's sometimes much
easier to define a condition that must be true if the code is correct
than to prove that the code actually satisfies the condition.

It does not (necessarily) defend against the "dumbness" of the
programmer.  It defends against mistakes by the programmer.
Perhaps you never make mistakes, but most of us do.

I suggest you try to understand it before you claim that it, and
programmers who use it, are stupid.

I use them all the time, so Herbert's assertion may have serious
merit.

They have great value for me and have probably saved me a thousand
hours of debugging time.

But smarter programmers probably don't need them.

P.S.
For a masterful use of assertions (IMO) examine this code:
http://arctrix.com/nas/chess/fruit/

P.P.S.
Fabian is a really nice guy.

 

[user923005]

I use them all the time, so Herbert's assertion may have serious
merit.

They have great value for me and have probably saved me a thousand
hours of debugging time.

But smarter programmers probably don't need them.

P.S.
For a masterful use of assertions (IMO) examine this code:http://arctrix.com/nas/chess/fruit/

P.P.S.
Fabian is a really nice guy.

At the time it was written, this was the strongest chess engine in the
world (it has now been surpassed):

Subject: SSDF Rating List 2006-01-03
Author: Thoralf Karlsson
Date: 07:01:26 01/03/06
--------------------------------------------------------------------------------
THE SSDF RATING LIST 2006-01-03 1104075 games played by 274
computers
Rating + - Games
Won Oppo
------ --- --- -----
--- ----
1 Fruit 2.2.1 256MB Athlon 1200 MHz 2852 35 -33 457
68% 2717
2 Fritz 9.0 256MB Athlon 1200 MHz 2819 32 -30 587
74% 2639
3 Shredder 9.0 UCI 256MB Athlon 1200 MHz 2818 24 -23 995
70% 2667
4 Shredder 8.0 CB 256MB Athlon 1200 MHz 2805 23 -22 1115
71% 2648
5 Shredder 7.04 UCI 256MB Athlon 1200 MHz 2801 22 -21 1175
68% 2669
6 Junior 9.0 256MB Athlon 1200 MHz 2786 25 -24 826
64% 2682
7 Deep Fritz 8.0 256MB Athlon 1200 MHz 2781 24 -23 982
69% 2642
8 Junior 8.0 256MB Athlon 1200 MHz 2766 24 -24 888
65% 2660
9 Shredder 7.0 256MB Athlon 1200 MHz 2765 26 -25 841
69% 2629
10 Deep Fritz 7.0 256MB Athlon 1200 MHz 2764 24 -23 938
65% 2654

 

[Mark]

Well, I don't think it's a good example. Here's a better one (I
hope!). Consider a function whose documentation says something like:

/* function: si_digital_root
library: libstrint.a
purpose: returns the digital root of a specified number of
digits in a given string

[skip]
Thanks a lot, this neat example does help to understand.

while(start <= end)
{
assert(isdigit(s[start])); /* D */
root += s[start] - '0';
root %= 10;
}

'start' is not being advanced towards the end. Is it a copy-paste typo?

 

[Nick Keighley]

assert() uis there for brainless programmers to save theyr brain.

P.J.Plauger uses assert() in his library book.

In
more than 25years programming I found no sense for assert.

assert evaluates to a NOOP when compiling NOT in debug mode, so it
does nothing in produnction code.

More exactly, assert() evaluates to a null statement if NDEBUG
is defined.

assert in debug mode makes no sense because when you as writer of the
code does a check against your dumbness you have found the bug already
but too dumb to resolve it.

assert is not designed to make a test against data - it can only
defend against the dumbness of the programmer that writes the assert,
it can't defend against dumbness the user using the program.

So assert is at least completely useless.

assert() is of no use to people, such as yourself, who never
make mistakes.

 

[James Kuyper]

Richard Heathfield wrote:
....

Right. (Well, nearly. The Standard doesn't actually define a "debug
mode", but I think we all know what you mean!)

In the context of a discussion of assert(), and in particular in
reference to "evaluates to a NOOP", debug mode is pretty clearly the
mode when NDEBUG is not #defined.

 

[Hallvard B Furuseth]

In the real world, users tend not to enjoy broken code very much, and
will try to avoid vendors who ship it to them.

If, of course, they have an alternative which suits them better.

That claim made such a perfect hook for a small rant on absolute
statements, so let me turn it around: "If you're not confident
enough of the code to release it WITH assertions in place, it is
not yet ready for release."

I think each statement makes equally little sense by itself. Real
life code has bugs, and we need some policy for dealing with them.


I've had an email program delete random messages - or attach
messages to each other so when I e.g. deleted a spam I might also
delete next message. Dunno why, maybe a corrupted data structure.
One typical suspect was an American program using 'char' values as
indexes which could thus be negative when they met my 8-bit
charset. An entirely different part of the program, e.g. fopen(),
might have noticed that. If so I'd really, really have liked some
module - any module - to assert() before I lost more mail.

OTOH if the system was really buggy, such asserts would crash it
all the time. Then I'd be, er, exactly in the position of young
computer enthusiasts decades ago who wanted free programs rather
than paying for them, however unreliable they were. Except I
assume many did that badly even without asserts, which would make
it suicidal for vendors with competitors to turn asserts on.

BTW, I notice you're posting with a free newsreader, as do I

Getting back to fopen(), though - it notices it has entered
undefined behavior, maybe due to an argument, maybe an internal
problem. Should it crash or just return failure? How serious
harm is the error a symptom of? If it returns failure and/or logs
a message to stderr, will the user even know or is it just some
daemon which will log a message in some obscure file? If the user
sees the message, will he just try again to open the file, maybe
succeeding this time? As the vendor providing that fopen(), how
do you decide?

Turning asserts on or off make most sense depend among other
things on policy, how actively the code it is supported, the
quality of the code, the quality of third-party code which calls
your code, your guess about the harm a bug can do, the
harm/annoyance a crash can do, and thus how much you know of what
your code is used _for_. Without any of that, ask a soothsayer.

 

[Hallvard B Furuseth]

(...)

That claim made such a perfect hook for a small rant on absolute
statements, so (...)

Hmm, looking at your statements about asserts in libraries elsethread
I'm not quite sure if you ment it that absolutely, but in any case,
thanks for a chance to rant a bit.

 

[James Kuyper]

Hallvard B Furuseth wrote:
....

I've had an email program delete random messages - or attach
messages to each other so when I e.g. deleted a spam I might also
delete next message. Dunno why, maybe a corrupted data structure.
One typical suspect was an American program using 'char' values as
indexes which could thus be negative when they met my 8-bit
charset. An entirely different part of the program, e.g. fopen(),
might have noticed that. If so I'd really, really have liked some
module - any module - to assert() before I lost more mail.

Your assumption seems to be that the alternative to an assert() is a
crash. The things that you would use assert() for during debugging fall
into two categories:

A) Possibilities that, as a result of your testing, you are now certain
will never come up. If you're paying proper attention to reality, this
will be a very small set of possibilities. In this case, it doesn't
matter whether you keep assert(), or turn it off by #defining NDEBUG,
and for the sake of efficiency I'd prefer to turn them off.

B) Possibilities that, despite your testing, you are not completely
certain will never turn up. If you're paying proper attention to
reality, these will be the overwhelming majority of the possibilities.
For production code, assert() is usually the wrong way to deal with
these possibilities. What should happen instead is that the program
should continue to test for these possibilities, and if they come up,
deal with them gracefully, and not simply by aborting.

 

[Hallvard B Furuseth]

Hallvard B Furuseth wrote:
...

Your assumption seems to be that the alternative to an assert() is a
crash.

What? My assumption is that one alternative is to not crash, but
instead let worse damage happen. A failed assert is a crash. Unless
they're disabled. I should have said I'd have liked something, anything
to exit the program - even if just by crashing it. Sure, a nicer
failure mode would be better. But assert is what C provides, and an
assert() crash would was my cheapest hope to save that mail.

The things that you would use assert() for during debugging fall
into two categories:

The things I would use assert() for during debugging fall anywhere in
the range from "WTF is going on?" to "this can't happen unless someone
breaks this code, so why not leave it in just to be safe".

(...)
B) Possibilities that, despite your testing, you are not completely
certain will never turn up. If you're paying proper attention to
reality, these will be the overwhelming majority of the
possibilities. For production code, assert() is usually the wrong way to
deal with these possibilities. What should happen instead is that the
program should continue to test for these possibilities, and if they
come up, deal with them gracefully, and not simply by aborting.

Yes, code should of course test for bugs in itself and nearby code, and
try to deal gracefully with them. And asserts should of course be
limited to tests where you could be bothered to write the test but not
with coming up with and coding a graceful exit strategy, or where a
"graceful exit strategy" has no or negative value since what you want is
a crash during testing.

Even so, real life doesn't measure up to your ideal of production code,
or any reasonable person's ideal for that matter.

We work in an industry where various minor and major players alike have
made it the norm to loudly, blatantly proclaim the poor quality of our
products, and first managed to get users to accept this, and then even
got the users to purchace the service of fixing the messes the products
make for them. OK, quality is getting more attention again, but do try
to paste a common "NO WARRANTY...NO LIABILITY..." notice on a house or a
food product and sell it.

Of course that happened in part because that's what users voted for with
their feet and pocketbooks: Cheap or free programs with the mostest
features, rather than quality.

I work somewhere between your ideal and the reality quoted above. So,
clearly, do authors of several programs I use. So, in a sense, does the
C language, where still nobody has managed to get around go agree on
(i.e. standardize) more nuance to failure than assert vs atexit.

 

[Hallvard B Furuseth]

Whilst that is a true statement, it is not a good argument, at least
not from where I'm sitting. One of my uses for assertions is runtime
checking of the structural integrity of (sometimes very large)
dynamic data structures. This imposes an overhead that I am happy to
accept during debugging, but not in production code. The assertions
are there to help me discover bugs.

Well, yes. Like I said below, I don't agree with that statement myself.

The main gripe with assert() is that it is so crude, in more than one
way. Just a single on/off switch (NDEBUG), so you need to pick a single
level of overhead/danger of crash/whatever to accept for your asserts.
Or, of course, #define a private range of assert macros that'd expand to
assert() or (void)0 or something more graceful, depending on build
options. I don't understand why I see so little of that, in particular
in code which does use asserts in production.

As Richard Bos pointed out,
assertions are a terrible way to report bugs to users - but they are
a great way to report bugs to programmers.

True enough.

Inadequate testing on target platform. Assertions are not a substitute
for testing.

Real life. Computer industry dominated by Americans, who maybe or maybe
not tested their programs just fine with 7-bit English text messages.
Then we non-English folks came along and wanted to use existing software
with our character sets rather than wait a decade for it to grow up to
work properly with 8-bit data.

It /can/ do whatever it likes if the behaviour is undefined. What it
/should/ do depends on your priorities. These differ amongst
programmers.

I don't get it, if we are still talking about production code. Isn't
that more or less what I was saying, only briefer? Are you saying what
possibly fopen /should/ assert() in production after all, depending on
my priorities?