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

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
OSR
@OSRDrivers

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.

-Pro

On Jul 9, 2018, at 8:23 AM, xxxxx@osr.com 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: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>