So smelly or not we have a lot of stuff that branches conditionally based on return codes from whatever was just called. CLI *,0 and *,255 along with CR R11,R11 gives a range of options for indicating if something was good, bad or indifferent.
The ability to insert (say) a logging routine to trace an operation by using an IPM / <log> / SPM and not having to do the <expensive cc setting routine> over again or worry that <log> changed the cc outweighs the idea that doing <expensive cc setting operation> twice is somehow more intellectually pure. YMMV, but it works. In production. Consistently. I’ll take that over running IDF at 3am. > On Dec 7, 2018, at 9:08 PM, Robin Vowels <robi...@dodo.com.au> wrote: > > > EXTERNAL > ====================================================================== > From: "Brent Longborough" <br...@longborough.org> > Sent: Friday, December 07, 2018 11:24 PM > > >> IMHO this is a Code Smell. >> If you need the CC in order to print it out for debugging, it's probably >> more useful to print the data that led to that CC. >> If you want to save the CC, go off somewhere and do something else, and >> restore the CC when you get back, that can be buggy > > It's not going to be "buggy". > It's simple and trivial. > >> and make debugging difficult. >> For me, it's better (where simple enough) to repeat the test that >> produced the CC: the code is much clearer. > > Why repeat the computation. That can be buggy, > because some of the values used in arriving at the CC > may have been changed in the meantime. > >> If the test cannot be reproduced after the "something else", then it's >> conceivable that the CC isn't even valid any more, > > The CC can be restored trivially. > >> and, of course, >> debugging the original setting of that CC is likely to be difficult. > > No it isn't. > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus
