[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 25 Jul 2015 14:38:13 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Coding Style
---- Frank Dittrich <frank.dittrich@...lbox.org> wrote:
> On 07/25/2015 06:51 PM, jfoug@....net wrote:
> > ---- magnum <john.magnum@...hmail.com> wrote:
> >> On 2015-07-25 15:05, Kai Zhao wrote:
> >>> Chapter 7: Centralized exiting of functions
> >>
> >> Same here.
> >
> > This one can probably be dropped. We have enough auto bug finding tools now (mem leaks, etc), that after someone gets their hand slapped once or twice, then will learn the power of the goto for cleanup. Most of the valid()/salt() are already written this way if they allocate temp buffers.
>
> May be it is needed, see the recent commit
> b46ecf2329584c1d0a9e91f8b0ad3a4f4344165b.
There 'are' 5 styles that I can think of, when it comes to writing validation type functions.
1. what valid()? simply skip doing it. A crash tells you if the data is valid or not. (not for JtR)
2. what leak? Valid() simply returns when something is not valid (again, not for JtR)
3. cleanup at every invalid location (what the above commit does). Prone to errors, and leaks
4. goto is evil. Write complex overly nested conditional logic so we never goto. Often prone to have logic errors and missed validation.
5. using goto error; each time a validation check fails, and then the code after error: is smart enough to clean up well (I recommend this method).
So, I sort of can see why describing style 5 is something that would not be a bad thing.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
