Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

RE: RE: RE: RE: Re: [BULK] Re: Modern C++ Features in Kernel Mode Drivers

Peter_ViscarolaPeter_Viscarola Posts: 6,649

> if(status) goto done;
> Which of them do you think is easier to read and maintain???

I have seen code like this before. I personally prefer nested if's to facilitate
cleanup lining up clearly through horizontal indentation. Both approaches I
think are ugly. It's a developer decision.


Like so many things in my engineering life, my opinion on these topics has changed over the years.

For many years, I favored the "early out" pattern of multiple return points from a function... because this was the most common pattern seen in Windows kernel mode "back in the day".

I *really* don't like if NT_SUCCESS() ... if NT_SUCCESS() ... if NT_SUCCESS()... indent. I find this to be both ugly and confusing. To ME, the logic gets lost in the error handling. Then again, I still insist on code being no wider than 80 columns.

A few years back, just about everyone here at OSR has uniformly switched to the "goto done" model, and this has proved *very* satisfactory. I find the code easy to follow, and indents from the left follow the code *logic* not the success path for function invocation.

But, as Mr. Kreamer said, "it's a developer decision"... every man should be able to select his own tools.


Peter Viscarola


  • Prokash_SinhaProkash_Sinha Posts: 1,214
    I used std::lock_guard in quite a few places, but in UM. Not in KM. I certainly don’t hate it, and see the benefit.

    There are so many things, like RAII, f(….) const etc., that have been around for long, but driver/kernel community of all platforms using just C, in most cases. Look at linux, os x etc.

    > On Jul 9, 2018, at 8:23 AM, <> wrote:
    >> I don't like hiding stuff when in kernel mode, so I spend as
    >> less time as possible in kernel debugging
    > The problem is, one person's "hiding" is another's safety. Do RAII patterns "hide" things, in your view?
    > Take std::lock_guard as an example. Do you hate this?
    > I, for one, *love* this paradigm for locking... You're not *hiding* the lock release, it's just implicit as part of the acquisition. Take the time and write a few comments if clarity concerns you, for goodness sakes.
    > When using std::lock_guard, there's no chance of confusion because "we all know" what lock_guard does.
    > The only potential problem I see with this pattern is if you create your own RAII patterned class "PGV_Acquire_Spinlock(PKSPIN_LOCK)" in your driver (this does work BTW), it *might* take somebody a few minutes to figure out how that works... But with judicious appropriate comments, all should be well, and your chances of leaving the function's scope without releasing the lock are zero.
    > Peter
    > OSR
    > @OSRDrivers
    > ---
    > NTDEV is sponsored by OSR
    > Visit the list online at: <>;
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    > Details at <>;
    > To unsubscribe, visit the List Server section of OSR Online at <>;
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!