🚀 go-pugleaf

In article <9009082252.AA16290@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes:
>In article <1428@proto.COM> you write:
>>  assert(i++ < limit);
>
>Asserts with side effects have always been a bad idea, ...
>
>This is a famous problem by now, I know lots of programs that couldn't be
>shipped with NDEBUG set exactly because there were side effects in the
>asserts.  (I think this is an argument for better programmer education
>rather than fudging the language to the tastes of sloppy programmers.)

Existing C history aside, I think it would be much more robust to
define assert in such a way that such things can't happen. Turning off
debugging shouldn't introduce bugs! Sure, you can blame it on the
programmers, but since C is a language which permits side effects in
conditional expressions, I think the proper function of assert's (i.e.
a mechanism to INCREASE program reliability) would be better served if
they were implemented in such a way as to always evaluate their
argument, as Mr. Levine suggests.

With any decent compiler, this change won't add additional overhead to
most uses of asserts (i.e. where the condition obviously has no side
effects and can be discarded). Where there are actually side effects,
they will take effect; this is extra code but it might also affect
what the program does (i.e., the side effect might be necessary for
correct operation). The only place where it's clearly additional
wasted overhead is where a function call is involved that has no side
effects. 

The big problem, of course, is that it breaks with existing practice.
However, I don't think it's "fudging" the language to suggest that
existing practice might be improved upon.
-- 
Jim Patterson                              Cognos Incorporated
UUCP:uunet!mitel!sce!cognos!jimp           P.O. BOX 9707    
PHONE:(613)738-1440                        3755 Riverside Drive
                                           Ottawa, Ont  K1G 3Z4