Re-checking the ReactOS project - a large report

Re-checkingtheReactOSproject-alarge

report

Author: Andrey Karpov

Date: 02.04.2013

The ReactOS project is rapidly developing. One of the developers participating in this project suggested

that we re-analyzed the source code, as the code base is growing fast. We were glad to do that. We like

this project, and we'll be happy if this article helps the developers to eliminate some bugs. Analysis was

performed with the PVS-Studio 5.02 code analyzer.

Let me remind you what ReactOS is. This is a free and open-source operating system based on the

Windows NT architecture principles. The system was developed from scratch and therefore is not based

on Linux and doesn't have anything in common with the UNIX architecture. The main aim of the ReactOS

project is to create a Windows binary-compatible operating system that would allow users to execute

Windows-compatible applications and drivers as if they were executed in Windows itself.

We analyzed this project once some time ago. The results of that check were described in the post "PVS-

Studio: analyzing ReactOS's code". After re-checking the project, we have found a lot of new bugs and

suspicious code fragments. This fact proves very well that static code analysis should be performed

regularly, not occasionally! Doing it that way will help you to significantly reduce the number of errors

at the stage of coding already, which means that errors detected will take much less time to eliminate.

Note that the article describes far not all the fragments worth considering. ReactOS has become a big

boy now: the solution includes 803 projects. For those, the PVS-Studio analyzer has generated a good

deal of general warnings:

1. 1320 first-level warnings;

2. 814 second-level warnings;

3. 2753 third-level warnings.

It was natural that I didn't find enough courage just to sit down and study all these warnings in detail.

So, I'll only point at the most suspicious fragments that caught my glance. There certainly must be other

warnings that should be examined as attentively; and there are also diagnostics related to 64-bit errors

and micro-optimizations which I didn't examine at all.

The PVS-Studio demo version will be insufficient to examine all the 4887 warnings. However, we are

friendly to open-source projects: if the ReactOS developers ask us, we'll give them our tool for free for a

while.

Misprints PVS-Studio is good at detecting various misprints. We may call it its "hobbyhorse". This is a very useful

function, as misprints inevitably exist in any project. Let's see what ReactOS has to show us in this field.

Variable overwrite NTSTATUS NTAPI CreateCdRomDeviceObject(....)

{

....

cddata->XAFlags &= ~XA_USE_6_BYTE;

cddata->XAFlags = XA_USE_READ_CD | XA_USE_10_BYTE;

....

}

V519 The 'cddata->XAFlags' variable is assigned values twice successively. Perhaps this is a mistake.

Check lines: 1290, 1291. cdrom.c 1291

The assignment operation overwrites the previous value of the XAFlags term. The following text should

be most likely written instead: cddata->XAFlags |= XA_USE_READ_CD | XA_USE_10_BYTE;. But of course

I can't be quite sure, as I don't know the logic of this code.

Repetition in condition void util_blit_pixels_writemask(....)

{

....

if ((src_tex == dst_surface->texture &&

dst_surface->u.tex.level == src_level &&

dst_surface->u.tex.first_layer == srcZ0) ||

(src_tex->target != PIPE_TEXTURE_2D &&

src_tex->target != PIPE_TEXTURE_2D &&

src_tex->target != PIPE_TEXTURE_RECT))

....

}

V501 There are identical sub-expressions 'src_tex->target != PIPE_TEXTURE_2D' to the left and to the

right of the '&&' operator. u_blit.c 421

The check "src_tex->target != PIPE_TEXTURE_2D" is executed twice. It's another constant that the

'target' term must be compared to for the second time. Otherwise this comparison is unnecessary.

Here's another error of this kind:

static boolean is_legal_int_format_combo(

const struct util_format_description *src,

const struct util_format_description *dst )

{

....

for (i = 0; i < nr; i++) {

/* The signs must match. */

if (src->channel[i].type != src->channel[i].type) {

return FALSE;

}

....

}

V501 There are identical sub-expressions 'src->channel[i].type' to the left and to the right of the '!='

operator. translate_generic.c 776

The correct check seems to be as follows: src->channel[i].type != dst->channel[i].type.

And one more similar error:

static GpStatus draw_poly(....)

{

....

if((i + 2 >= count) ||

!(types[i + 1] & PathPointTypeBezier) ||

!(types[i + 1] & PathPointTypeBezier))

{

ERR("Bad bezier points\n");

goto end;

}

....

}

V501 There are identical sub-expressions '!(types[i + 1] & PathPointTypeBezier)' to the left and to the

right of the '||' operator. graphics.c 1912

One more:

static inline BOOL is_unc_path(const WCHAR *str) {

return (str[0] == '\\' && str[0] == '\\');

}

V501 There are identical sub-expressions to the left and to the right of the '&&' operator: str[0] == '\\'

&& str[0] == '\\' uri.c 273

By the way, this particular bug remains unfixed since the previous check. I didn't describe it in the

previous article, although it is included into my error samples base. Don't remember why I didn't

mention it - perhaps I was concerned about not making the article too large. The developers must have

never run PVS-Studio on their project, and the bug has successfully survived inside the code for at least a

couple of years.

One more:

VOID NTAPI UniAtaReadLunConfig(....)

{

if(!LunExt->IdentifyData.SectorsPerTrack ||

!LunExt->IdentifyData.NumberOfCylinders ||

!LunExt->IdentifyData.SectorsPerTrack)

....

}

V501 There are identical sub-expressions '!LunExt->IdentifyData.SectorsPerTrack' to the left and to the

right of the '||' operator. id_init.cpp 1528

The error is quite obvious, I believe. Don't know how to fix it.

Be patient - I have some other twin bugs to show you. And I can't help it... You see, these are very

typical software bugs.

ir_visitor_status

ir_validate::visit_leave(ir_loop *ir)

{

if (ir->counter != NULL) {

if ((ir->from == NULL) || (ir->from == NULL) ||

(ir->increment == NULL)) {

....

}

V501 There are identical sub-expressions to the left and to the right of the '||' operator: (ir->from == 0)

|| (ir->from == 0) ir_validate.cpp 123

One of the "ir->from == 0" comparisons must be replaced with "ir->to == NULL".

The same error, caused through the copy-paste technology, can be found here: V501 There are identical

sub-expressions to the left and to the right of the '||' operator: (ir->from != 0) || (ir->from != 0)

ir_validate.cpp 139

Unnecessary semicolon

We have finally got to another class of misprints - the unnecessary semicolon ';' that spoils everything.

int BlockEnvToEnvironA(void)

{

....

for (envptr--; envptr >= _environ; envptr--);

free(*envptr);

....

}

V529 Odd semicolon ';' after 'for' operator. environ.c 67

Note the ';' character after the 'for' operator. It results in the free() function being called only once,

which leads to memory leaks. It also causes releasing a memory area that wasn't intended to be

released. This is how the incorrect code works in its present state:

free(envptr >= _environ ? _environ[-1] : envptr);

The same semicolons can be found here:

• V529 Odd semicolon ';' after 'for' operator. environ.c 119

• V529 Odd semicolon ';' after 'for' operator. environ.c 171

Incorrect expression static HRESULT WINAPI JScriptSafety_SetInterfaceSafetyOptions(

...., DWORD dwEnabledOptions)

{

....

This->safeopt = dwEnabledOptions & dwEnabledOptions;

return S_OK;

}

V501 There are identical sub-expressions to the left and to the right of the '&' operator:

dwEnabledOptions & dwEnabledOptions jscript.c 905

One of the operands seems to have an incorrectly defined name in the expression.

Here's a misprint that causes the size of a rectangle to be calculated incorrectly.

GpStatus WINGDIPAPI GdipGetRegionBoundsI(....)

{

....

status = GdipGetRegionBounds(region, graphics, &rectf);

if (status == Ok){

rect->X = gdip_round(rectf.X);

rect->Y = gdip_round(rectf.X);

rect->Width = gdip_round(rectf.Width);

rect->Height = gdip_round(rectf.Height);

}

return status;

}

V656 Variables 'rect->X', 'rect->Y' are initialized through the call to the same function. It's probably an

error or un-optimized code. Consider inspecting the 'gdip_round(rectf.X)' expression. Check lines: 718,

719. region.c 719

I'm almost sure that the following code must be written here: "rect->Y = gdip_round(rectf.Y);". If it's not

so, there should be some comment on this.

The following is a code fragment where a variable is assigned to itself:

DWORD WINAPI

DdGetDriverInfo(LPDDHAL_GETDRIVERINFODATA pData)

{

....

pUserColorControl->dwFlags = pUserColorControl->dwFlags;

....

}

V570 The 'pUserColorControl->dwFlags' variable is assigned to itself. gdientry.c 1029

The assignment is meaningless. The expression must be incomplete, or something is messed up. The

same error here:

V570 The 'Irp->IoStatus.Information' variable is assigned to itself. hidclass.c 461

Let's talk about null pointers If you have a C/C++ application, you have troubles with pointers. This is the price we have to pay for the

language's efficiency. However, C++ and especially C++11 offer a number of ways to avoid handling wild

pointers. But that is a subject to be discussed individually.

Let's see what can be found in ReactOS regarding this kind of bugs.

Null pointer dereferencing static void acpi_bus_notify (....)

{

struct acpi_device *device = NULL;

....

switch (type) {

....

case ACPI_NOTIFY_EJECT_REQUEST:

DPRINT1("Received EJECT REQUEST "

"notification for device [%s]\n",

device->pnp.bus_id);

break;

....

}

}

V522 Dereferencing of the null pointer 'device' might take place. bus.c 762

If the "case ACPI_NOTIFY_EJECT_REQUEST:" branch is chosen in the 'switch' operator, the 'device'

pointer will still be equal to zero at the moment. Dereferencing it in the "device->pnp.bus_id"

expression will have unpleasant consequences.

In the same bad way the 'device' variable is used in some other fragments:

• V522 Dereferencing of the null pointer 'device' might take place. bus.c 768




Here's another code fragment where a variable remains equal to zero by the moment it must be used:

ir_texture *ir_reader::read_texture(s_expression *expr)

{

s_symbol *tag = NULL;

....

} else if (MATCH(expr, other_pattern)) {

op = ir_texture::get_opcode(tag->value());

if (op == -1)

return NULL;

}

....

}

V522 Dereferencing of the null pointer 'tag' might take place. ir_reader.cpp 904

At the moment of calling the value() function, the 'tag' variable will still equal zero. That's no good.

There are some other similar null pointer dereferencing bugs found in ReactOS:

• V522 Dereferencing of the null pointer 's_shadow' might take place. ir_reader.cpp 964

• V522 Dereferencing of the null pointer 'BootSectorInfo' might take place. disksup.c 1750



Passing a null pointer into a function BOOL GetEventCategory(....)

{

....

if (lpMsgBuf)

{

....

}

else

{

wcscpy(CategoryName, (LPCWSTR)lpMsgBuf);

}

....

}

V575 The null pointer is passed into 'wcscpy' function. Inspect the second argument. eventvwr.c 270

The wcscpy() function is called only if the 'lpMsgBuf' variable equals zero. This variable is passed as an

argument into the 'wcscpy' function. It's hooliganism to pass zero into the 'wcscpy' function.

Here, another hooligan is torturing a cat the strstr() function:

VOID WinLdrSetupEms(IN PCHAR BootOptions)

{

PCHAR RedirectPort;

....

if (RedirectPort)

{

....

}

else

{

RedirectPort = strstr(RedirectPort, "usebiossettings");

....

}

V575 The null pointer is passed into 'strstr' function. Inspect the first argument. headless.c 263

The _wcsicmp() function has suffered for company as well:

DWORD ParseReasonCode(LPCWSTR code)

{

LPWSTR tmpPrefix = NULL;

....

for (reasonptr = shutdownReason ; reasonptr->prefix ; reasonptr++)

{

if ((majorCode == reasonptr->major) &&

(minorCode == reasonptr->minor) &&

(_wcsicmp(tmpPrefix, reasonptr->prefix) != 0))

{

return reasonptr->flag;

}

}

....

}

V575 The null pointer is passed into '_wcsicmp' function. Inspect the first argument. misc.c 150

By the time the _wcsicmp() function must be called, the pointer tmpPrefix is still a null pointer.

Dereferencing a possible null pointer

There are very many code fragments where the pointer is first dereferenced and only then is checked

for being a null pointer. It's not always an error. Perhaps the pointer simply cannot be a null pointer, and

the check is just unnecessary. But such code usually appears due to inattention and is incorrect. It works

only until the unhappy pointer suddenly becomes a null pointer through a coincidence.

I will cite only one simple example here:

static BOOL LookupSidInformation(....)

{

....

DomainName = &PolicyAccountDomainInfo->DomainName;

SidNameUse = (PolicyAccountDomainInfo != NULL ?

SidTypeGroup : SidTypeUser);

....

}

V595 The 'PolicyAccountDomainInfo' pointer was utilized before it was verified against nullptr. Check

lines: 254, 257. sidcache.c 254

Look, the 'PolicyAccountDomainInfo' pointer is dereferenced first. And then it is suddenly checked for

being a null pointer. Such a code is usually created as a result of swift refactoring. Variables are starting

to be used when there are not checked yet.

The reason why I'm describing only one error of this kind is that they all look much alike. And also

because they are AWFULLY NUMEROUS. I'm not interested in examining and describing each individual

case. Moreover, it's impossible to include them all into the article - it would then be a reference book

instead. That's why I'll just cite the diagnostic messages for you:

• V595 The 'oldRelations' pointer was utilized before it was verified against nullptr. Check lines:

216, 246. pnp.c 216

• V595 The 'Op->Common.Value.Arg' pointer was utilized before it was verified against nullptr.

Check lines: 531, 554. dswload.c 531

• V595 The 'OutOp' pointer was utilized before it was verified against nullptr. Check lines: 325,

346. dswexec.c 325

• V595 The 'Poll' pointer was utilized before it was verified against nullptr. Check lines: 63, 66.

select.c 63

• V595 The 'pEdit' pointer was utilized before it was verified against nullptr. Check lines: 480, 491.

editstream.c 480

• V595 The 'plpOptions[curStream]' pointer was utilized before it was verified against nullptr.

Check lines: 1629, 1630. api.c 1629

• V595 The 'pThis' pointer was utilized before it was verified against nullptr. Check lines: 454, 461.

atlwin.h 454

• V595 The 'pThis' pointer was utilized before it was verified against nullptr. Check lines: 639, 646.

atlwin.h 639

• V595 The 'DeviceObject' pointer was utilized before it was verified against nullptr. Check lines:

6870, 6877. class.c 6870

• V595 The 'extName' pointer was utilized before it was verified against nullptr. Check lines: 128,

141. assoc.c 128

• V595 The 'FileList' pointer was utilized before it was verified against nullptr. Check lines: 775,

791. filecomp.c 775

• V595 The 'ident' pointer was utilized before it was verified against nullptr. Check lines: 449, 462.

set.c 449

• V595 The 'psp' pointer was utilized before it was verified against nullptr. Check lines: 2705,

2714. propsheet.c 2705

• V595 The 'lpItem' pointer was utilized before it was verified against nullptr. Check lines: 4256,

4269. listview.c 4256

• V595 The 'lpFindInfo' pointer was utilized before it was verified against nullptr. Check lines:

6199, 6203. listview.c 6199

• V595 The 'item' pointer was utilized before it was verified against nullptr. Check lines: 1461,

1463. treeview.c 1461

• V595 The 'file' pointer was utilized before it was verified against nullptr. Check lines: 2799, 2802.

file.c 2799

• V595 The 'context' pointer was utilized before it was verified against nullptr. Check lines: 976,

1006. cryptnet_main.c 976

• V595 The 'advanced' pointer was utilized before it was verified against nullptr. Check lines: 436,

451. main.c 436

• V595 The 'compiland' pointer was utilized before it was verified against nullptr. Check lines: 389,

396. symbol.c 389

• V595 The 'func' pointer was utilized before it was verified against nullptr. Check lines: 468, 471.

symbol.c 468

• V595 The 'compiland' pointer was utilized before it was verified against nullptr. Check lines: 589,

594. symbol.c 589

• V595 The 'pMapper' pointer was utilized before it was verified against nullptr. Check lines: 822,

847. createdevenum.c 822

• V595 The 'psh.phpage' pointer was utilized before it was verified against nullptr. Check lines:

2475, 2494. advprop.c 2475

• V595 The 'DevAdvPropInfo' pointer was utilized before it was verified against nullptr. Check

lines: 2480, 2508. advprop.c 2480

• V595 The 'DeviceID' pointer was utilized before it was verified against nullptr. Check lines: 296,

303. enumdevices.c 296


4279, 4284. disk.c 4279

• V595 The 'device->hwbuf' pointer was utilized before it was verified against nullptr. Check lines:

917, 927. mixer.c 917

• V595 The 'PtrNewFileObject' pointer was utilized before it was verified against nullptr. Check

lines: 306, 322. create.c 306

• V595 The 'PtrSourceFCB->FCBName' pointer was utilized before it was verified against nullptr.

Check lines: 2793, 2812. metadata.c 2793

• V595 The 'FileObject' pointer was utilized before it was verified against nullptr. Check lines: 54,

60. fastio.c 54


680. fastio.c 663


749. fastio.c 733

• V595 The 'PtrCCB' pointer was utilized before it was verified against nullptr. Check lines: 1018,

1021. fastio.c 1018

• V595 The 'PtrCCB' pointer was utilized before it was verified against nullptr. Check lines: 1093,

1102. fastio.c 1093

• V595 The 'pData' pointer was utilized before it was verified against nullptr. Check lines: 330,

340. inode.c 330

• V595 The 'ext2_bdl' pointer was utilized before it was verified against nullptr. Check lines: 532,

537. inode.c 532

• V595 The 'ext2_bdl' pointer was utilized before it was verified against nullptr. Check lines: 600,

615. inode.c 600

• V595 The 'IrpContext' pointer was utilized before it was verified against nullptr. Check lines: 922,

925. finfo.c 922

• V595 The 'IrpContext' pointer was utilized before it was verified against nullptr. Check lines: 396,

399. volume.c 396

• V595 The 'rwContext' pointer was utilized before it was verified against nullptr. Check lines: 224,

235. fbtrwr.c 224

• V595 The 'DataSize' pointer was utilized before it was verified against nullptr. Check lines: 695,

699. registry.c 695

• V595 The 'DataSize' pointer was utilized before it was verified against nullptr. Check lines: 733,

737. registry.c 733

• V595 The 'mm' pointer was utilized before it was verified against nullptr. Check lines: 287, 290.

pb_bufmgr_mm.c 287

• V595 The 'pool' pointer was utilized before it was verified against nullptr. Check lines: 315, 320.

pb_bufmgr_pool.c 315

• V595 The 'cache' pointer was utilized before it was verified against nullptr. Check lines: 186,

189. u_cache.c 186

• V595 The 'cache' pointer was utilized before it was verified against nullptr. Check lines: 221,

224. u_cache.c 221

• V595 The 'src' pointer was utilized before it was verified against nullptr. Check lines: 163, 166.

u_surface.c 163

• V595 The 'graphics' pointer was utilized before it was verified against nullptr. Check lines: 2239,

2255. graphics.c 2239

• V595 The 'vlist' pointer was utilized before it was verified against nullptr. Check lines: 69, 73.

trimvertpool.cc 69

• V595 The 'vlist' pointer was utilized before it was verified against nullptr. Check lines: 88, 93.

trimvertpool.cc 88

• V595 The 'LocalItemState' pointer was utilized before it was verified against nullptr. Check lines:

64, 70. parser.c 64

• V595 The 'sd->zone_mgr' pointer was utilized before it was verified against nullptr. Check lines:

246, 249. security.c 246

• V595 The 'entitySet' pointer was utilized before it was verified against nullptr. Check lines: 519,

535. ipstats_reactos.c 519

• V595 The 'disp' pointer was utilized before it was verified against nullptr. Check lines: 509, 515.

jscript.c 509

• V595 The 'a_cBuffer' pointer was utilized before it was verified against nullptr. Check lines: 888,

893. debugger.c 888

• V595 The 'AutomationTableB' pointer was utilized before it was verified against nullptr. Check

lines: 1903, 1905. api.c 1903


lines: 1952, 1954. api.c 1952


lines: 2001, 2003. api.c 2001


lines: 2347, 2350. api.c 2347

• V595 The 'IoStack->FileObject' pointer was utilized before it was verified against nullptr. Check

lines: 611, 622. device.c 611

• V595 The 'Ctx' pointer was utilized before it was verified against nullptr. Check lines: 425, 430.

event.c 425

• V595 The 'BusDeviceExtension' pointer was utilized before it was verified against nullptr. Check

lines: 1388, 1390. swenum.c 1388

• V595 The 'path' pointer was utilized before it was verified against nullptr. Check lines: 3250,

3254. catalog.c 3250

• V595 The 'str2' pointer was utilized before it was verified against nullptr. Check lines: 395, 396.

c14n.c 395

• V595 The 'atts' pointer was utilized before it was verified against nullptr. Check lines: 3763,

3775. htmlparser.c 3763

• V595 The 'ctxt' pointer was utilized before it was verified against nullptr. Check lines: 3674,

3676. htmlparser.c 3674

• V595 The 'ctxt->input' pointer was utilized before it was verified against nullptr. Check lines:

6693, 6697. htmlparser.c 6693

• V595 The 'name' pointer was utilized before it was verified against nullptr. Check lines: 123, 131.

hash.c 123

• V595 The 'ctxt->nsTab' pointer was utilized before it was verified against nullptr. Check lines:

1546, 1553. parser.c 1546


6690, 6698. parser.c 6690


6750, 6758. parser.c 6750

• V595 The 'atts' pointer was utilized before it was verified against nullptr. Check lines: 8477,

8486. parser.c 8477


11113, 11116. parser.c 11113

• V595 The 'ctx->myDoc' pointer was utilized before it was verified against nullptr. Check lines:

12784, 12787. parser.c 12784

• V595 The 'ctxt->myDoc' pointer was utilized before it was verified against nullptr. Check lines:

13341, 13357. parser.c 13341

• V595 The 'oldctxt' pointer was utilized before it was verified against nullptr. Check lines: 13349,

13367. parser.c 13349

• V595 The 'tmp' pointer was utilized before it was verified against nullptr. Check lines: 1536,

1537. relaxng.c 1536

• V595 The 'lib' pointer was utilized before it was verified against nullptr. Check lines: 8598, 8604.

relaxng.c 8598

• V595 The 'ctxt->myDoc' pointer was utilized before it was verified against nullptr. Check lines:

984, 986. sax2.c 984

• V595 The 'ctxt->incTab' pointer was utilized before it was verified against nullptr. Check lines:

392, 400. xinclude.c 392

• V595 The 'href' pointer was utilized before it was verified against nullptr. Check lines: 518, 529.

xinclude.c 518

• V595 The 'ctxt' pointer was utilized before it was verified against nullptr. Check lines: 1129,

1130. xinclude.c 1129

• V595 The 'ctxt->incTab[nr]' pointer was utilized before it was verified against nullptr. Check

lines: 1419, 1428. xinclude.c 1419

• V595 The 'p' pointer was utilized before it was verified against nullptr. Check lines: 586, 589.

xmlmemory.c 586

• V595 The 'node' pointer was utilized before it was verified against nullptr. Check lines: 2819,

2829. xmlschemastypes.c 2819

• V595 The 'attr' pointer was utilized before it was verified against nullptr. Check lines: 2858,

2862. xmlschemas.c 2858

• V595 The 'uses' pointer was utilized before it was verified against nullptr. Check lines: 14498,

14508. xmlschemas.c 14498

• V595 The 'atom->ranges' pointer was utilized before it was verified against nullptr. Check lines:

817, 818. xmlregexp.c 817

• V595 The 'exec->state' pointer was utilized before it was verified against nullptr. Check lines:

4263, 4273. xmlregexp.c 4263

• V595 The 'res' pointer was utilized before it was verified against nullptr. Check lines: 14032,

14054. xpath.c 14032

• V595 The 'msg' pointer was utilized before it was verified against nullptr. Check lines: 361, 363.

rostcp.c 361

• V595 The 'msg' pointer was utilized before it was verified against nullptr. Check lines: 469, 473.

rostcp.c 469

• V595 The 'last_unsent' pointer was utilized before it was verified against nullptr. Check lines:

632, 661. tcp_out.c 632

• V595 The 'att->Renderbuffer' pointer was utilized before it was verified against nullptr. Check

lines: 790, 798. fbobject.c 790

• V595 The 'sub_prims' pointer was utilized before it was verified against nullptr. Check lines: 852,

859. st_draw.c 852

• V595 The 'height' pointer was utilized before it was verified against nullptr. Check lines: 2471,

2474. teximage.c 2471

• V595 The 'WorkItem' pointer was utilized before it was verified against nullptr. Check lines: 745,

753. notify.c 745

• V595 The 'lpErrno' pointer was utilized before it was verified against nullptr. Check lines: 425,

439. dllmain.c 425

• V595 The 'pServiceFailureActions' pointer was utilized before it was verified against nullptr.

Check lines: 175, 184. srvpage.c 175

• V595 The 'This->pITextStoreACP' pointer was utilized before it was verified against nullptr.

Check lines: 143, 147. context.c 143

• V595 The 'sidsize' pointer was utilized before it was verified against nullptr. Check lines: 1998,

2002. registry.c 1998

• V595 The 'locator->pParserCtxt' pointer was utilized before it was verified against nullptr. Check

lines: 2290, 2301. saxreader.c 2290

• V595 The 'DstBuffer' pointer was utilized before it was verified against nullptr. Check lines: 100,

101. buffer.c 100

• V595 The 'SrcBuffer' pointer was utilized before it was verified against nullptr. Check lines: 159,

160. buffer.c 159


265. buffer.c 264


276. buffer.c 275


628. buffer.c 627


639. buffer.c 638

• V595 The 'DstBuffer' pointer was utilized before it was verified against nullptr. Check lines:

1249, 1250. buffer.c 1249


1263. buffer.c 1262


1048. 8390.c 1047


900. main.c 899

• V595 The 'EnumContext' pointer was utilized before it was verified against nullptr. Check lines:

596, 599. local_group.c 596

• V595 The 'EnumContext' pointer was utilized before it was verified against nullptr. Check lines:

1344, 1347. user.c 1344

• V595 The '* ptr' pointer was utilized before it was verified against nullptr. Check lines: 85, 88.

nbnamecache.c 85

• V595 The 'wki' pointer was utilized before it was verified against nullptr. Check lines: 129, 133.

netid.c 129


netid.c 163


netid.c 299

• V595 The 'SafeParams' pointer was utilized before it was verified against nullptr. Check lines:

608, 624. harderr.c 608

• V595 The 'ObjectCreateInfo' pointer was utilized before it was verified against nullptr. Check

lines: 707, 732. oblife.c 707

• V595 The 'ListHead' pointer was utilized before it was verified against nullptr. Check lines: 103,

104. pfnlist.c 103

• V595 The 'ImpersonationInfo' pointer was utilized before it was verified against nullptr. Check

lines: 56, 60. security.c 56

• V595 The 'CapturedPrivileges' pointer was utilized before it was verified against nullptr. Check

lines: 2256, 2277. token.c 2256

• V595 The 'pv' pointer was utilized before it was verified against nullptr. Check lines: 809, 831.

variant.c 809

• V595 The 'result' pointer was utilized before it was verified against nullptr. Check lines: 3394,

3401. variant.c 3394

• V595 The 'result' pointer was utilized before it was verified against nullptr. Check lines: 3585,


• V595 The 'pVarOut' pointer was utilized before it was verified against nullptr. Check lines: 5248,


• V595 The 'typeInfo' pointer was utilized before it was verified against nullptr. Check lines: 867,

869. typelib.c 867

• V595 The 'subtypeinfo' pointer was utilized before it was verified against nullptr. Check lines:

4960, 4965. typelib.c 4960

• V595 The 'pTLib' pointer was utilized before it was verified against nullptr. Check lines: 7082,

7084. typelib.c 7082


612, 624. fdo.c 612

• V595 The 'Package' pointer was utilized before it was verified against nullptr. Check lines: 170,

187. init.c 170

• V595 The 'Package' pointer was utilized before it was verified against nullptr. Check lines: 462,

469. init.c 462

• V595 The 'Adapter' pointer was utilized before it was verified against nullptr. Check lines: 998,

1004. pcnet.c 998

• V595 The 'm_pInterruptSync' pointer was utilized before it was verified against nullptr. Check

lines: 1610, 1627. miniport_dmus.cpp 1610

• V595 The 'DSImpl->dsbuffer' pointer was utilized before it was verified against nullptr. Check

lines: 882, 898. dsoundrender.c 882

• V595 The 'pcFetched' pointer was utilized before it was verified against nullptr. Check lines: 199,

204. enummedia.c 199

• V595 The 'pParser' pointer was utilized before it was verified against nullptr. Check lines: 868,

872. filtermapper.c 868

• V595 The 'pPropBag' pointer was utilized before it was verified against nullptr. Check lines: 920,

928. filtermapper.c 920

• V595 The 'pPropBagCat' pointer was utilized before it was verified against nullptr. Check lines:

1342, 1366. filtermapper.c 1342

• V595 The 'pPropBagCat' pointer was utilized before it was verified against nullptr. Check lines:

784, 797. filtergraph.c 784

• V595 The 'pFM2' pointer was utilized before it was verified against nullptr. Check lines: 644,

654. regsvr.c 644

• V595 The 'pAlloc' pointer was utilized before it was verified against nullptr. Check lines: 900,

905. pin.c 900

• V595 The 'pMemConnected' pointer was utilized before it was verified against nullptr. Check

lines: 941, 947. pin.c 941


972. pin.c 970


1001. pin.c 999


1030. pin.c 1028

• V595 The 'pMemAlloc' pointer was utilized before it was verified against nullptr. Check lines:

1704, 1709. pin.c 1704

• V595 The 'This->pMemInputPin' pointer was utilized before it was verified against nullptr. Check

lines: 1716, 1725. pin.c 1716

• V595 The 's' pointer was utilized before it was verified against nullptr. Check lines: 778, 799.

recyclebin_v5.c 778

• V595 The 'prbel' pointer was utilized before it was verified against nullptr. Check lines: 230, 248.

recyclebin.c 230

• V595 The 'ppszNames' pointer was utilized before it was verified against nullptr. Check lines:

238, 245. find.c 238

• V595 The 'ppszNames' pointer was utilized before it was verified against nullptr. Check lines:

464, 485. find.c 464

• V595 The 'para' pointer was utilized before it was verified against nullptr. Check lines: 211, 213.

caret.c 211

• V595 The 'lpObject' pointer was utilized before it was verified against nullptr. Check lines: 1151,

1173. editor.c 1151

• V595 The 'lpDataObject' pointer was utilized before it was verified against nullptr. Check lines:

1152, 1176. editor.c 1152

• V595 The 'lpOleCache' pointer was utilized before it was verified against nullptr. Check lines:

1150, 1177. editor.c 1150

• V595 The 'argv' pointer was utilized before it was verified against nullptr. Check lines: 354, 358.

rundll32.c 354

• V595 The 'pServiceStatus' pointer was utilized before it was verified against nullptr. Check lines:

131, 144. query.c 131

• V595 The 'pServiceStatus' pointer was utilized before it was verified against nullptr. Check lines:

191, 197. query.c 191

• V595 The 'oleobj' pointer was utilized before it was verified against nullptr. Check lines: 357,

365. dochost.c 357

• V595 The 'urlfile' pointer was utilized before it was verified against nullptr. Check lines: 220,

235. iexplore.c 220

• V595 The 'urlobj' pointer was utilized before it was verified against nullptr. Check lines: 223,

238. iexplore.c 223

• V595 The 'pDrvDefExt' pointer was utilized before it was verified against nullptr. Check lines:

161, 177. drive.cpp 161

• V595 The 'pszList' pointer was utilized before it was verified against nullptr. Check lines: 589,

606. dialogs.cpp 589

• V595 The 'pFileDefExt' pointer was utilized before it was verified against nullptr. Check lines:

142, 157. fprop.cpp 142

• V595 The 'pidl' pointer was utilized before it was verified against nullptr. Check lines: 757, 760.

pidl.cpp 757

• V595 The 'pidlInOut' pointer was utilized before it was verified against nullptr. Check lines: 136,

156. shlfolder.cpp 136

• V595 The 'cm' pointer was utilized before it was verified against nullptr. Check lines: 1296, 1303.

shlexec.cpp 1296

• V595 The 'pcchOut' pointer was utilized before it was verified against nullptr. Check lines: 2238,

2240. url.c 2238

• V595 The 'NewSubsystem' pointer was utilized before it was verified against nullptr. Check lines:

500, 502. smsubsys.c 500

• V595 The 'OutputMdl' pointer was utilized before it was verified against nullptr. Check lines:

1382, 1408. dispatch.c 1382


101. buffer.c 100


160. buffer.c 159


267. buffer.c 266


278. buffer.c 277

• V595 The 'lpszTemp' pointer was utilized before it was verified against nullptr. Check lines: 997,

1000. taskmgr.c 997

• V595 The 'AtaReq' pointer was utilized before it was verified against nullptr. Check lines: 4944,

4972. id_ata.cpp 4944

• V595 The 'AtaReq' pointer was utilized before it was verified against nullptr. Check lines: 4899,

4925. id_ata.cpp 4899

• V595 The 'Srb' pointer was utilized before it was verified against nullptr. Check lines: 9664,

9666. id_ata.cpp 9664

• V595 The 'Srb' pointer was utilized before it was verified against nullptr. Check lines: 9652,

9666. id_ata.cpp 9652

• V595 The 'builder->uri' pointer was utilized before it was verified against nullptr. Check lines:

5250, 5262. uri.c 5250

• V595 The 'pInstance' pointer was utilized before it was verified against nullptr. Check lines: 387,

388. ddeserver.c 387

• V595 The 'current_line' pointer was utilized before it was verified against nullptr. Check lines:

524, 529. edit.c 524

• V595 The 'es' pointer was utilized before it was verified against nullptr. Check lines: 5195, 5214.

edit.c 5195

• V595 The 'pBSMInfo' pointer was utilized before it was verified against nullptr. Check lines:

3146, 3158. message.c 3146

• V595 The 'pHwnd' pointer was utilized before it was verified against nullptr. Check lines: 673,

679. window.c 673

• V595 The 'levels' pointer was utilized before it was verified against nullptr. Check lines: 1572,

1578. usp10.c 1572

• V595 The '* root' pointer was utilized before it was verified against nullptr. Check lines: 548,

553. check.c 548

• V595 The 'VbeInfo' pointer was utilized before it was verified against nullptr. Check lines: 206,

207. vbemodes.c 206

• V595 The 'pClient->hPins' pointer was utilized before it was verified against nullptr. Check lines:

237, 242. entry.c 237

• V595 The 'Context.ProcessData' pointer was utilized before it was verified against nullptr. Check

lines: 853, 861. exitros.c 853

• V595 The 'pstrLibName' pointer was utilized before it was verified against nullptr. Check lines:

136, 140. callback.c 136

• V595 The 'psurfColor' pointer was utilized before it was verified against nullptr. Check lines:

1176, 1182. cursoricon.c 1176

• V595 The 'DestRect' pointer was utilized before it was verified against nullptr. Check lines: 33,

36. copybits.c 33

• V595 The 'SourcePoint' pointer was utilized before it was verified against nullptr. Check lines:

34, 36. copybits.c 34

• V595 The 'pdesk->pDeskInfo->spwnd' pointer was utilized before it was verified against nullptr.

Check lines: 148, 150. desktop.c 148

• V595 The 'psurfPattern' pointer was utilized before it was verified against nullptr. Check lines:

342, 365. engbrush.c 342

• V595 The 'WndPrev' pointer was utilized before it was verified against nullptr. Check lines: 62,

65. focus.c 62

• V595 The 'Wnd' pointer was utilized before it was verified against nullptr. Check lines: 374, 384.

focus.c 374

• V595 The 'pti->rpdesk' pointer was utilized before it was verified against nullptr. Check lines:

358, 364. input.c 358

• V595 The 'pStrokes' pointer was utilized before it was verified against nullptr. Check lines: 1941,

1947. path.c 1941

• V595 The 'dc' pointer was utilized before it was verified against nullptr. Check lines: 933, 958.

palette.c 933

• V595 The 'SourceRect' pointer was utilized before it was verified against nullptr. Check lines:

402, 430. stretchblt.c 402

• V595 The 'Wnd' pointer was utilized before it was verified against nullptr. Check lines: 390, 403.

windc.c 390

• V595 The 'pPatterns' pointer was utilized before it was verified against nullptr. Check lines: 512,

533. info.c 512

• V595 The 'converter' pointer was utilized before it was verified against nullptr. Check lines:

2164, 2172. info.c 2164

• V595 The 'context' pointer was utilized before it was verified against nullptr. Check lines: 95,

100. texture.c 95

• V595 The 'Globals.win_list' pointer was utilized before it was verified against nullptr. Check

lines: 560, 583. winhelp.c 560

• V595 The 'lpwh' pointer was utilized before it was verified against nullptr. Check lines: 1400,

1414. ftp.c 1400

• V595 The 'optval' pointer was utilized before it was verified against nullptr. Check lines: 284,

296. sockctrl.c 284

Macros

Macros are bad - of that I'm still dead sure. You should use regular functions wherever possible.

Someone felt too lazy to make a full-fledged function stat64_to_stat() in ReactOS and contented

himself/herself with creating a shit-macro. This is what it looks like:

#define stat64_to_stat(buf64, buf) \

buf->st_dev = (buf64)->st_dev; \

buf->st_ino = (buf64)->st_ino; \

buf->st_mode = (buf64)->st_mode; \

buf->st_nlink = (buf64)->st_nlink; \

buf->st_uid = (buf64)->st_uid; \

buf->st_gid = (buf64)->st_gid; \

buf->st_rdev = (buf64)->st_rdev; \

buf->st_size = (_off_t)(buf64)->st_size; \

buf->st_atime = (time_t)(buf64)->st_atime; \

buf->st_mtime = (time_t)(buf64)->st_mtime; \

buf->st_ctime = (time_t)(buf64)->st_ctime; \

Let's see how this macro is used in the _tstat function:

int CDECL _tstat(const _TCHAR* path, struct _stat * buf)

{

int ret;

struct __stat64 buf64;

ret = _tstat64(path, &buf64);

if (!ret)

stat64_to_stat(&buf64, buf);

return ret;

}

Do you think the 'stat64_to_stat' macro is executed if the 'ret' variable equals zero? It is absolutely not.

The macro is expanded into a set of separate lines. That's why only the "buf->st_dev = (buf64)-

>st_dev;" line refers to the 'if' operator, while all the other lines will be executed all the time!

There are other fragments that employ this incorrect macro:

• V640 The code's operational logic does not correspond with its formatting. The second

statement will always be executed. It is possible that curly brackets are missing. stat.c 35





Conditions which are always true/false

Here's an issue when an always true condition might cause an infinite loop.

#define DISKREADBUFFER_SIZE HEX(10000)

typedef unsigned short USHORT, *PUSHORT;

static VOID DetectBiosDisks(....)

{

USHORT i;

....

Changed = FALSE;

for (i = 0; ! Changed && i < DISKREADBUFFER_SIZE; i++)

{

Changed = ((PUCHAR)DISKREADBUFFER)[i] != 0xcd;

}

....

}

V547 Expression 'i < 0x10000' is always true. The value range of unsigned short type: [0, 65535].

xboxhw.c 358

The loop is meant to search through the DISKREADBUFFER array for a byte whose value doesn't equal

'0xCD'. If such a byte doesn't exist, the 'Changed' variable always has the FALSE value. In this case, the "i

< DISKREADBUFFER_SIZE" expression is the truncation condition. As this expression is always true, the

program will start iterating an infinite loop.

The error is this: the 'i' variable has the 'unsigned short' type. It can take values within the range from 0

to 65535. These values are always below '0x10000'.

A typical error I often see in many projects is the assumption that SOCKET is a signed variable. It's not so.

To be more exact, it depends on the library implementation.

typedef UINT_PTR SOCKET;

#define ADNS_SOCKET SOCKET

struct adns__state {

....

ADNS_SOCKET udpsocket, tcpsocket;

....

};

static int init_finish(adns_state ads) {

....

if (ads->udpsocket<0) { r= errno; goto x_free; }

....

}

V547 Expression 'ads->udpsocket < 0' is always false. Unsigned type value is never < 0. setup.c 539

The 'udpsocket' variable is unsigned, which means that the 'ads->udpsocket < 0' condition is always

false. To figure out where the error has occurred we need to use the SOCKET_ERROR constant.

Similar socket handling errors can be found here:

• V547 Expression 'fd < 0' is always false. Unsigned type value is never < 0. event.c 117

• V547 Expression 'ads->udpsocket >= 0' is always true. Unsigned type value is always >= 0.

check.c 105

• V547 Expression 'ads->tcpsocket >= 0' is always true. Unsigned type value is always >= 0. check.c

114

• V547 Expression 'ads->tcpsocket >= 0' is always true. Unsigned type value is always >= 0. check.c

123

Incorrect checks may lead to buffer overflows and, consequently, to undefined behavior. Here's a

sample where the exception handler fails.

BOOL PrepareService(LPCTSTR ServiceName)

{

DWORD LeftOfBuffer = sizeof(ServiceKeyBuffer) /

sizeof(ServiceKeyBuffer[0]);

....

LeftOfBuffer -= _tcslen(SERVICE_KEY);

....

LeftOfBuffer -= _tcslen(ServiceName);

....

LeftOfBuffer -= _tcslen(PARAMETERS_KEY);

....

if (LeftOfBuffer < 0)

{

DPRINT1("Buffer overflow for service name: '%s'\n",

ServiceName);

return FALSE;

}

....

}

V547 Expression 'LeftOfBuffer < 0' is always false. Unsigned type value is never < 0. svchost.c 51

The 'LeftOfBuffer' variable should most likely be a signed one.

It often happens that unsigned variables cause function return values to be checked incorrectly. Here's

such a code:

static INT FASTCALL

MenuButtonUp(MTRACKER *Mt, HMENU PtMenu, UINT Flags)

{

UINT Id;

....

Id = NtUserMenuItemFromPoint(....);

....

if (0 <= Id &&

MenuGetRosMenuItemInfo(MenuInfo.Self, Id, &ItemInfo) &&

MenuInfo.FocusedItem == Id)

....

}

V547 Expression '0 <= Id' is always true. Unsigned type value is always >= 0. menu.c 2663

The NtUserMenuItemFromPoint() function can return the negative value (-1). The error occurs because

of the 'Id' variable being unsigned. That results in the '0 <= Id' check being meaningless.

A function parameter is checked incorrectly in the following code fragment.

typedef unsigned int GLuint;

const GLubyte *_mesa_get_enabled_extension(

struct gl_context *ctx, GLuint index)

{

const GLboolean *base;

size_t n;

const struct extension *i;

if (index < 0)

return NULL;

....

}

V547 Expression 'index < 0' is always false. Unsigned type value is never < 0. extensions.c 936

It's not interesting to discuss V547 warnings any further, so let me just cite the remaining fragments I've

noticed:

• V547 Expression 'index >= 0' is always true. Unsigned type value is always >= 0.

st_glsl_to_tgsi.cpp 4013

• V547 Expression 'index >= 0' is always true. Unsigned type value is always >= 0.

st_glsl_to_tgsi.cpp 4023

• V547 Expression 'index < 0' is always false. Unsigned type value is never < 0. st_glsl_to_tgsi.cpp

4027

• V547 Expression '(src[i]) < (0)' is always false. Unsigned type value is never < 0. texstore.c 3692

• V547 Expression '(src[i]) < (0)' is always false. Unsigned type value is never < 0. texstore.c 3759

• V547 Expression 'CommitReduction >= 0' is always true. Unsigned type value is always >= 0.

virtual.c 4784

• V547 Expression 'Info->nPage < 0' is always false. Unsigned type value is never < 0. scrollbar.c

428

• V547 Expression 'Entry->Id <= 0xffff' is always true. The value range of unsigned short type: [0,

65535]. res.c 312

Undefined behavior and Unspecified behavior. You must not shift negative numbers - even if the code that has these shifts seems to work successfully

for a long time. It is incorrect. It leads to undefined or unspecified behavior. The issue may reveal itself

when you start using another platform or another compiler or change optimization switches. I discussed

negative number shifts in detail in the article "Wade not in unknown waters. Part three".

This is an incorrect code sample:

static INLINE int wrap(short f, int shift)

{

....

if (f < (-16 << shift))

....

}

V610 Undefined behavior. Check the shift operator '<<. The left operand '-16' is negative.

vl_mpeg12_bitstream.c 653

No one knows what the (-16 << shift) expression is equal to. Other similar fragile code samples can be

found in the following fragments:

• V610 Undefined behavior. Check the shift operator '<<. The left operand '(- 1)' is negative.

jdarith.c 460


jdhuff.c 930


layer1.c 86


layer1.c 90


layer1.c 97


layer1.c 118

• V610 Unspecified behavior. Check the shift operator '>>. The left operand is negative ('i' = [-

4096..4095]). tabinit.c 269

• V610 Unspecified behavior. Check the shift operator '>>. The left operand is negative ('i' = [-

4096..4095]). tabinit.c 274

• V610 Undefined behavior. Check the shift operator '<<. The left operand '-1' is negative. mppc.c

351

Incorrect format specifier Let's have a look at several samples demonstrating incorrect ways of using variadic functions to print

variable values.

UINT64 Size;

static HRESULT STDMETHODCALLTYPE

CBindStatusCallback_OnProgress(....)

{

....

_tprintf(_T("Length: %ull\n"), This->Size);

....

}

V576 Incorrect format. Consider checking the second actual argument of the 'wprintf' function. The

argument is expected to be not greater than 32-bit. dwnl.c 228

You should write "%llu" instead of "%ull" to print a 64-bit variable.

Using "%u" is one more incorrect way to print the pointer value. There exists the "%p" specifier for this

purpose. However, the programmer must have made a misprint in the code below, and it is "%s" that

should have been written there.

BOOL CALLBACK EnumPickIconResourceProc(

HMODULE hModule, LPCWSTR lpszType,

LPWSTR lpszName, LONG_PTR lParam)

{

....

swprintf(szName, L"%u", lpszName);

....

}

V576 Incorrect format. Consider checking the third actual argument of the 'swprintf' function. To print

the value of pointer the '%p' should be used. dialogs.cpp 66

The errors when Unicode and non-Unicode strings are used together are very frequent. For example, if

you need to print a UNICODE character in the fprintf() function, you should use '%C', not '%c'. Here's an

incorrect code sample with that error:

int WINAPI WinMain(....)

{

LPWSTR *argvW = NULL;

....

fprintf(stderr,

"Unknown option \"%c\" in Repair mode\n",

argvW[i][j]);

....

}

V576 Incorrect format. Consider checking the third actual argument of the 'fprintf' function. The char

type argument is expected. msiexec.c 655

The same bugs can be found in the following fragments:

• V576 Incorrect format. Consider checking the third actual argument of the 'fprintf' function. The

char type argument is expected. msiexec.c 705

• V576 Incorrect format. Consider checking the third actual argument of the 'swprintf' function.

The pointer to string of wchar_t type symbols is expected. sminit.c 1831


The pointer to string of char type symbols is expected. bootsup.c 600


The pointer to string of char type symbols is expected. guiconsole.c 328







Operation priorities

I've found several errors related to operation priorities confusion.

static HRESULT BindStatusCallback_create(....)

{

HRESULT hr;

....

if ((hr = SafeArrayGetUBound(sa, 1, &size) != S_OK))

{

SafeArrayUnaccessData(sa);

return hr;

}

....

}

V593 Consider reviewing the expression of the 'A = B != C' kind. The expression is calculated as

following: 'A = (B != C)'. httprequest.c 692

According to operation priorities in C/C++, the "SafeArrayGetUBound(sa, 1, &size) != S_OK" comparison

is executed in the first place, while it is only then that assignment is performed. However, the condition

will work well. The incorrect thing is that the 'hr' variable will store 0 or 1 instead of the status. The

function will therefore return an incorrect status.

Here is another very similar error:

static void symt_fill_sym_info(....)

{

....

if (sym->tag != SymTagPublicSymbol ||

!(dbghelp_options & SYMOPT_UNDNAME) ||

(sym_info->NameLen =

UnDecorateSymbolName(name, sym_info->Name,

sym_info->MaxNameLen, UNDNAME_NAME_ONLY) == 0))

....

}

V593 Consider reviewing the expression of the 'A = B == C' kind. The expression is calculated as

following: 'A = (B == C)'. symbol.c 801

The code is difficult to read. But if you look close, you'll notice that the UnDecorateSymbolName()

function's return result is compared to zero first, then the comparison result is put into the 'sym_info-

>NameLen' variable.

Array index out of bounds FF_T_WCHAR FileName[FF_MAX_FILENAME];

FF_T_UINT32 FF_FindEntryInDir(....) {

....

FF_T_WCHAR *lastPtr = pDirent->FileName + sizeof(pDirent->FileName);

....

lastPtr[-1] = '\0';

....

}

V594 The pointer steps out of array's bounds. ff_dir.c 260

The programmer intended 'lastPtr' to point at a memory cell after that last character in the string. That

won't happen though. The string consists of WCHAR characters. It means that it's the buffer size that is

added, not the number of characters. And that value is twice larger than necessary. When writing the

null character, the array index out of bounds error with all its implications will occur.

This is what the fixed code looks like:

FF_T_WCHAR *lastPtr = pDirent->FileName +

sizeof(pDirent->FileName) / sizeof(pDirent->FileName[0]);

The strncat() function is pretty dangerous regarding this class of bugs. The reason is that it's not the total

buffer size that the last argument should specify, but how many more characters can be put into it.

Because of misunderstanding this thing, programmers write unsafe code:

void shell(int argc, const char *argv[])

{

char CmdLine[MAX_PATH];

....

strcpy( CmdLine, ShellCmd );

if (argc > 1)

{

strncat(CmdLine, " /C", MAX_PATH);

}

for (i=1; i<argc; i++)

{

strncat(CmdLine, " ", MAX_PATH);

strncat(CmdLine, argv[i], MAX_PATH);

}

....

}

V645 The 'strncat' function call could lead to the 'CmdLine' buffer overflow. The bounds should not

contain the size of the buffer, but a number of characters it can hold. cmds.c 1314





It cannot be guaranteed that no buffer overflow occurs. To learn more about this class of errors, see the

documentation (V645 diagnostic).

A similar trouble can be found here:

V645 The 'wcsncat' function call could lead to the 'szFileName' buffer overflow. The bounds should not

contain the size of the buffer, but a number of characters it can hold. logfile.c 50

Repetitions

Repetitions are related to conditions and can be of two types.

Type one. The same operations are executed regardless of the condition. For example:

void CardButton::DrawRect(HDC hdc, RECT *rect, bool fNormal)

{

....

if(fNormal)

hOld = SelectObject(hdc, hhi);

else

hOld = SelectObject(hdc, hhi);

....

}

V523 The 'then' statement is equivalent to the 'else' statement. cardbutton.cpp 86

Another example:

NTSTATUS NTAPI

CPortPinWavePci::HandleKsStream(IN PIRP Irp)

{

....

if (m_Capture)

m_Position.WriteOffset += Data;

else

m_Position.WriteOffset += Data;

....

}

V523 The 'then' statement is equivalent to the 'else' statement. pin_wavepci.cpp 562

One more repetition of a large code fragment can be found here:

V523 The 'then' statement is equivalent to the 'else' statement. tab.c 1043

Type two. A condition is repeated. It appears that the second condition will never hold. For example:

#define LOCALE_SSHORTDATE 31

#define LOCALE_SLONGDATE 32

MSVCRT__locale_t CDECL MSVCRT__create_locale(....)

{

....

if (time_data[i]==

LOCALE_SSHORTDATE && !lcid[LC_TIME]) {

size += ....;

} else if(time_data[i]==

LOCALE_SSHORTDATE && !lcid[LC_TIME]) {

size += ....;

} else {

....

}

V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error

presence. Check lines: 1193, 1195. locale.c 1193

I suppose that the second check should have been written in the following way:

if (time_data[i]==LOCALE_SLONGDATE && !lcid[LC_TIME])

Other similar repeating checks can be found here:

• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical

error presence. Check lines: 1225, 1228. locale.c 1225

• V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical

error presence. Check lines: 1241, 1244. locale.c 1241

Miscellaneous

Now let's have a look at diverse bugs.

Incorrect calculation of the characters number typedef struct _UNICODE_STRING {

USHORT Length;

USHORT MaximumLength;

PWSTR Buffer;

} UNICODE_STRING, *PUNICODE_STRING;

UNICODE_STRING DosDevices =

RTL_CONSTANT_STRING(L"\\DosDevices\\");

NTSTATUS CreateNewDriveLetterName(....)

{

....

DriveLetter->Buffer[

sizeof(DosDevices.Buffer) / sizeof(WCHAR)] =

(WCHAR)Letter;

....

}

V514 Dividing sizeof a pointer 'sizeof (DosDevices.Buffer)' by another value. There is a probability of

logical error presence. mountmgr.c 164

It seems that the "sizeof(DosDevices.Buffer) / sizeof(WCHAR)" expression was intended to calculate the

number of characters in a string. But 'DosDevices.Buffer' is just a pointer. As a result, the pointer size is

divided by 'sizeof(WCHAR)'. Other similar errors can be found here:

• V514 Dividing sizeof a pointer 'sizeof (DosDevices.Buffer)' by another value. There is a

probability of logical error presence. mountmgr.c 190

• V514 Dividing sizeof a pointer 'sizeof (DosDevices.Buffer)' by another value. There is a

probability of logical error presence. symlink.c 937

Here's another case of incorrect calculation of the number of characters in strings. In the following

sample it's multiplication instead of division:

VOID DisplayEvent(HWND hDlg)

{

WCHAR szEventType[MAX_PATH];

WCHAR szTime[MAX_PATH];

WCHAR szDate[MAX_PATH];

WCHAR szUser[MAX_PATH];

WCHAR szComputer[MAX_PATH];

....

ListView_GetItemText(...., sizeof(szEventType)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szDate)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szTime)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szSource)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szCategory)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szEventID)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szUser)*sizeof(WCHAR));

ListView_GetItemText(...., sizeof(szComputer)*sizeof(WCHAR));

....

}

It results in the ListView_GetItemText() function assuming that the buffer size is larger than it actually is.

It may potentially cause a buffer overflow.

Function return result not used #define strcmpW(s1,s2) wcscmp((s1),(s2))

static HRESULT WINAPI IEnumDMO_fnNext(....)

{

....

if (Names[count])

strcmpW(Names[count], szValue);

....

}

V530 The return value of function 'wcscmp' is required to be utilized. dmoreg.c 621

Uninitialized variable HRESULT WINAPI

INetCfgComponentControl_fnApplyRegistryChanges(

INetCfgComponentControl * iface)

{

HKEY hKey;

....

if (RegCreateKeyExW(hKey,

L"SYSTEM\\CurrentControlSet....",

....) == ERROR_SUCCESS)

....

}

V614 Uninitialized pointer 'hKey' used. Consider checking the first actual argument of the

'RegCreateKeyExW' function. tcpipconf_notify.c 3138

While calling the RegCreateKeyExW() function, the 'hKey' variable is not initialized yet.

High-order bits that may be significant get truncated HRESULT WINAPI CRecycleBin::CompareIDs(....)

{

....

return MAKE_HRESULT(SEVERITY_SUCCESS, 0,

(unsigned short)memcmp(pidl1->mkid.abID,

pidl2->mkid.abID,

pidl1->mkid.cb));

}

V642 Saving the 'memcmp' function result inside the 'unsigned short' type variable is inappropriate. The

significant bits could be lost breaking the program's logic. recyclebin.cpp 542

This type of errors is very much unobvious. I suggest that you read the description of the V642

diagnostic to understand the point. To put it briefly, the trouble is that the memcmp() function doesn't

necessarily return only values -1, 0, and 1. It may well return, for instance, number 0x100000. When

casting this number to the "unsigned short" type, it will turn into 0.

One-time loops

I've encountered several very strange loops. They don't have the 'continue' operator yet have the

unconditional operator 'break'. It means that the loop bodies are executed only once. Here's an example

of that kind.

VOID NTAPI IKsPin_PinCentricWorker(IN PVOID Parameter)

{

....

do

{

DPRINT("IKsPin_PinCentricWorker calling "

"Pin Process Routine\n");

Status =

This->Pin.Descriptor->Dispatch->Process(&This->Pin);

DPRINT("IKsPin_PinCentricWorker Status %lx, "

"Offset %lu Length %lu\n", Status,

This->LeadingEdgeStreamPointer.Offset,

This->LeadingEdgeStreamPointer.Length);

break;

} while(This->IrpCount);

}

V612 An unconditional 'break' within a loop. pin.c 1839

Other similar strange loops:

• V612 An unconditional 'break' within a loop. regexp.c 3633

• V612 An unconditional 'break' within a loop. hlpfile.c 1131

Strange things

There are code fragments which are probably not bugs. They are simply very strange. For example:

BOOLEAN NTAPI Ext2MakeNewDirectoryEntry(....)

{

....

MinLength = HeaderLength + NameLength;

MinLength = (HeaderLength + NameLength + 3) & 0xfffffffc;

....

}

V519 The 'MinLength' variable is assigned values twice successively. Perhaps this is a mistake. Check

lines: 948, 949. metadata.c 949

The 'MinLength' variable is assigned different values twice in a row. Perhaps it somehow helps in

debugging - I don't know. I would consider this an error, but there are many fragments of that kind

throughout the code. I won't mention them, as the post is already huge enough.

Conclusion I fail to make any wise conclusions. ReactOS is a rapidly growing and developing project. Hence it

contains quite a lot of errors. As you can see from this article, static analysis can catch a good deal of

them in a project like that. If one used it regularly, the benefit would be just invaluable.

Follow us on Twitter to keep track of PVS-Studio's new interesting feats in its struggle against bugs.

There we also post links to interesting articles on C/C++ programming and related subjects.

Technology

Re-checking the ReactOS project - a large report