.net - Making unsafe code safe in C# -

i reading through article on image processing in c#

there bit of code in there don't because it's unsafe, , know if can made safe:

public static bool invert(bitmap b) {     // gdi+ still lies - return format bgr, not rgb.      bitmapdata bmdata = b.lockbits(new rectangle(0, 0, b.width, b.height),          imagelockmode.readwrite, pixelformat.format24bpprgb);      int stride = bmdata.stride;      system.intptr scan0 = bmdata.scan0;      unsafe      {          byte * p = (byte *)(void *)scan0;         int noffset = stride - b.width*3;          int nwidth = b.width * 3;         for(int y=0;y < b.height;++y)         {             for(int x=0; x < nwidth; ++x )             {                 p[0] = (byte)(255-p[0]);                 ++p;             }             p += noffset;         }     }      b.unlockbits(bmdata);      return true; } 

the line byte* p = (byte*)(void*)scan0; looks culprit, have don't understand it's doing, or how made safe.

can shed light on please?

the unsafe code used performance reasons, mostly. basic idea you're going byte-by-byte on image data, , flipping each byte manually (although there's more efficient , simple ways handle same thing).

the underlying image handled gdi+, unmanaged code. when you're working image bytes directly, have manipulate unmanaged memory. how safe or unsafe is surprisingly tricky determine - depends lot on how unmanaged memory allocated. given you're working managed code, , loaded bitmap file or stream, it's pretty it's not unsafe, - there's no way accidentally overwrite managed memory, example. unsafe keyword's name doesn't come being inherently dangerous - comes allowing unsafe things. example, if allocated memory bitmap on own managed stack, mess things big time.

overall, it's practice use unsafe code if can prove it's worth costs. in image processing, quite trade-off - you're working tons of simple data, overheads in e.g. bounds checking can significant, though it's quite easy verify them once, rather in each iteration of cycle.

if wanted rid of unsafe code, 1 way allocate own byte[] (managed), use marshal.copy copy image data byte[], modifications in managed array, , copy results using marshal.copy again. thing is, means allocating byte[] big original image, , copying twice (the bounds checking negligible in scenario - .net jit compiler optimize away). , in end, it's still possible make mistake while using marshal.copy give same issues you'd have unsafe (not entirely, longer talk).

for me, far valuable part of having unsafe keyword allows localize unsafe stuff you're doing. while typical unmanaged application unsafe through , through, c# allows unsafe in marked parts of code. while can still affect rest of code (which 1 of reasons can use unsafe in fulltrust environment), makes them easier debug , control. it's trade-off, always.

however, code unsafe in different manner - unlockbits call may never happen if there's exception in middle of code. should use finally clauses ensure properer cleanup of unmanaged resources.

and final note, not doing image processing on cpu anyway, if want "real" performance, safe or unsafe. today, it's safe assume computer you're running on has gpu can job faster, easier , total isolation code running on computer itself.