How to make fewer errors at the stage of code writing. Part N1.


Published on

I've arrived at the source code of a widely know instant messenger Miranda IM. Together with various plugins, this is a rather large project whose size is about 950 thousand code lines in C and C++. And like any other considerable project with a long development history, it has rather many errors and misprints.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How to make fewer errors at the stage of code writing. Part N1.

  1. 1. How to make fewer errors at the stage ofcode writing. Part N1.Author: Andrey KarpovDate: 09.03.2011AbstractIve arrived at the source code of a widely know instant messenger Miranda IM Together with various IM.plugins, this is a rather large project whose size is about 950 thousand code lines in C and C++. And likeany other considerable project with a long development history, it has rather many errors and misprints.IntroductionWhile examining defects in various applications, I noticed some regularities. B the examples of defects Byfound in Miranda IM, I will try to formulate some recommendations that will help you to avoid manyerrors and misprints already at the stage of code writing.I used the PVS-Studio 4.14 analyzer to check Miranda IM. The Miranda IM project code is rather quality projectsand its popularity just confirms this fact. I am using this messenger myself and do not have anycomplaints about its quality. The project is built in Visual Studio with the Warning Level 3 ( (/W3) whilethe amount of comments makes 20% of the whole programs source.1. Avoid functions memset memcpy, ZeroMemory and the like memset,I will start with errors that occur when using low level functions to handle memory such as memset, low-levelmemcpy, ZeroMemory and the like like.I recommend you to avoid these functions by all means. Sure, you do not have to follow this tip literallyand replace all these functions with loops. But I have seen so many errors related to using thesefunctions that I strongly advise you to be very careful with them and use them only when it is reallynecessary. In my opinion, there are only two cases when using these functions is grounded n grounded:1) Processing of large arrays, i. in those places where you can really benefit from an optimized function , i.e.algorithm, as compared to simple looping.2) Processing large number of small arrays. The reason for this case also lies in performance gain lso gain.In all the other cases, youd better try to do without them. For instance, I believe that these functions dare unnecessary in such a program as Miranda. There are no resource intensive algorithms or large resource-intensivearrays in it. So, using functions memset/memcpy is determined only by the convenience of writing shortcode. But this simplicity is very deceptive and having saved a couple of seconds while writing the code,
  2. 2. you will spend weeks to catch this elusive memory corruption error. Lets examine several code samplestaken from the Miranda IM project.V512 A call of the memcpy function will lead to a buffer overflow or underflow. tabsrmm utils.cpp 1080typedef struct _textrangew{ CHARRANGE chrg; LPWSTR lpstrText;} TEXTRANGEW;const wchar_t* Utils::extractURLFromRichEdit(...){ ... ::CopyMemory(tr.lpstrText, L"mailto:", 7); ...}Only a part of the string is copied here. The error is awfully simple yet it remains. Most likely, there wasa string earlier consisting of char. Then they switched to Unicode strings but forgot to change theconstant.If you copy strings using functions which are designed quite for this purpose, this error can never occur.Imagine that this code sample was written this way:strncpy(tr.lpstrText, "mailto:", 7);Then the programmer did not have to change number 7 when switching to Unicode strings:wcsncpy(tr.lpstrText, L"mailto:", 7);I am not saying that this code is ideal. But it is much better than using CopyMemory. Consider anothersample.V568 Its odd that the argument of sizeof() operator is the & ImgIndex expression. clist_modernmodern_extraimage.cpp 302void ExtraImage_SetAllExtraIcons(HWND hwndList,HANDLE hContact){ ... char *(ImgIndex[64]); ...
  3. 3. memset(&ImgIndex,0,sizeof(&ImgIndex)); ...}The programmer intended to empty the array consisting of 64 pointers here. But only the first item willbe emptied instead. The same error, by the way, can be also found in another file. Thanks to our favoriteCopy-Paste:V568 Its odd that the argument of sizeof() operator is the & ImgIndex expression. clist_mwextraimage.c 295The correct code must look this way:memset(&ImgIndex,0,sizeof(ImgIndex));By the way, taking the address from the array might additionally confuse the one who is reading thecode. Taking of the address here is unreasonable and the code may be rewritten this way:memset(ImgIndex,0,sizeof(ImgIndex));The next sample.V568 Its odd that the argument of sizeof() operator is the & rowOptTA expression. clist_modernmodern_rowtemplateopt.cpp 258static ROWCELL* rowOptTA[100];void rowOptAddContainer(HWND htree, HTREEITEM hti){ ... ZeroMemory(rowOptTA,sizeof(&rowOptTA)); ...}Again, it is the pointers size which is calculated instead of the arrays size. The correct expression is"sizeof(rowOptTA)". I suggest using the following code to clear the array:const size_t ArraySize = 100;static ROWCELL* rowOptTA[ArraySize];...std::fill(rowOptTA, rowOptTA + ArraySize, nullptr);
  4. 4. I got used to meeting such lines which populate the code through the copy-paste method:V568 Its odd that the argument of sizeof() operator is the & rowOptTA expression. clist_modernmodern_rowtemplateopt.cpp 308V568 Its odd that the argument of sizeof() operator is the & rowOptTA expression. clist_modernmodern_rowtemplateopt.cpp 438You think that is all about low-level handling of arrays? No, quite not. Read further, fear and punishthose who like to use memset.V512 A call of the memset function will lead to a buffer overflow or underflow. clist_modernmodern_image_array.cpp 59static BOOL ImageArray_Alloc(LP_IMAGE_ARRAY_DATA iad, int size){ ... memset(&iad->nodes[iad->nodes_allocated_size], (size_grow - iad->nodes_allocated_size) * sizeof(IMAGE_ARRAY_DATA_NODE), 0); ...}This time, the size of copied data is calculated correctly, but the second and third arguments areswapped by mistake. Consequently, 0 items are filled. This is the correct code:memset(&iad->nodes[iad->nodes_allocated_size], 0, (size_grow - iad->nodes_allocated_size) * sizeof(IMAGE_ARRAY_DATA_NODE));I do not know how to rewrite this code fragment in a smarter way. To be more exact, you cannot makeit smart without touching other fragments and data structures.A question arises how to do without memset when handling such structures as OPENFILENAME:OPENFILENAME x;memset(&x, 0, sizeof(x));Its very simple. Create an emptied structure using this method:
  5. 5. OPENFILENAME x = { 0 };2. Watch closely and check if you are working with a signed or unsignedtypeThe problem of confusing signed types with unsigned types might seem farfetched at first sight. Butprogrammers make a big mistake by underestimating this issue.In most cases, people do not like to check compilers warning messages concerning the comparison ofan int-variable to an unsigned-variable. Really, such code is usually correct. So programmers disablethese warnings or just ignore them. Or, they resort to the third method - add an explicit type conversionto suppress the compilers warning without going into details.I suggest that you stop doing this and analyze the situation each time when a signed type meets anunsigned type. And in general, be careful about what type an expression has or what is returned by afunction. Now examine several samples on this subject.V547 Expression wParam >= 0 is always true. Unsigned type value is always >= 0. clist_mwcluiframes.c 3140There is the id2pos function in program code which returns value -1 for an error. Everything is OK withthis function. In another place, the result of id2pos function is used as shown below:typedef UINT_PTR WPARAM;static int id2pos(int id);static int nFramescount=0;INT_PTR CLUIFrameSetFloat(WPARAM wParam,LPARAM lParam){ ... wParam=id2pos(wParam); if(wParam>=0&&(int)wParam<nFramescount) if (Frames[wParam].floating) ...}The problem is that the wParam variable has an unsigned type. So, the condition wParam>=0 is alwaystrue. If id2pos function returns -1, the condition of checking for permissible values will not work and wewill start using a negative index.
  6. 6. I am almost sure that there was different code in the beginning:if (wParam>=0 && wParam<nFramescount)The Visual C++ compiler generated the warning "warning C4018: < : signed/unsigned mismatch". It isthis very warning that is enabled on Warning Level 3 with which Miranda IM is built. At that moment,the programmer paid little attention to this fragment. He suppressed the warning by an explicit typeconversion. But the error did not disappear and only hidden itself. This is the correct code:if ((INT_PTR)wParam>=0 && (INT_PTR)wParam<nFramescount)So, I urge you to be careful with such places. I counted 33 conditions in Miranda IM which are alwaystrue or always false due to confusion of signed/unsigned.Lets go on. I especially like the next sample. And the comment, it is just beautiful.V547 Expression nOldLength < 0 is always false. Unsigned type value is never < 0. IRC mstring.h 229void Append( PCXSTR pszSrc, int nLength ){ ... UINT nOldLength = GetLength(); if (nOldLength < 0) { // protects from underflow nOldLength = 0; } ...}I think there is no need in further explanations concerning this code.Of course, it is not only programmers fault that errors appear in programs. Sometimes librarydevelopers play a dirty trick on us (in this case it is developers of WinAPI).#define SRMSGSET_LIMITNAMESLEN_MIN 0static INT_PTR CALLBACK DlgProcTabsOptions(...){
  7. 7. ... limitLength = GetDlgItemInt(hwndDlg, IDC_LIMITNAMESLEN, NULL, TRUE) >= SRMSGSET_LIMITNAMESLEN_MIN ? GetDlgItemInt(hwndDlg, IDC_LIMITNAMESLEN, NULL, TRUE) : SRMSGSET_LIMITNAMESLEN_MIN; ...}If you ignore the excessively complicated expression, the code looks correct. By the way, it was onesingle line at first. I just arranged it into several lines to make it clearer. However, we are not discussingediting now.The problem is that the GetDlgItemInt() function returns quite not int as the programmer expected.This function returns UINT. This is its prototype from the "WinUser.h" file:WINUSERAPIUINTWINAPIGetDlgItemInt( __in HWND hDlg, __in int nIDDlgItem, __out_opt BOOL *lpTranslated, __in BOOL bSigned);PVS-Studio generates the following message:V547 Expression is always true. Unsigned type value is always >= 0. scriver msgoptions.c 458And it is really so. The "GetDlgItemInt(hwndDlg, IDC_LIMITNAMESLEN, NULL, TRUE) >=SRMSGSET_LIMITNAMESLEN_MIN" expression is always true.Perhaps there is no error in this particular case. But I think you understand what I am driving at. Becareful and check results your functions return.3. Avoid too many calculations in one stringEvery programmer knows and responsibly says at discussions that one should write simple and clearcode. But in practice it seems that programmers participate in a secret contest for the most intricatestring with an interesting language construct or skill of juggling with pointers.
  8. 8. Most often errors occur in those places where programmers gather several actions in one line to makecode compact. Making code just a bit smarter, they risk misprinting or missing some side effects.Consider this sample:V567 Undefined behavior. The s variable is modified while being used twice between sequence points.msn ezxml.c 371short ezxml_internal_dtd(ezxml_root_t root, char *s, size_t len){ ... while (*(n = ++s + strspn(s, EZXML_WS)) && *n != >) { ...}We have undefined behavior here. This code might work correctly for a long time but it is notguaranteed that it will behave the same way after moving to a different compilers version oroptimization switches. The compiler might well calculate ++s first and then call the function strspn(s,EZXML_WS). Or vice versa, it may call the function first and only then increment the s variable.Here you have another example on why you should not try to gather everything in one line. Someexecution branches in Miranda IM are disabled/enabled with inserts like && 0. For example:if ((1 || altDraw) && ...if (g_CluiData.bCurrentAlpha==GoalAlpha &&0)if(checkboxWidth && (subindex==-1 ||1)) {Everything is clear with these comparisons and they are well noticeable. Now imagine that you see afragment shown below. I have edited the code but initially it was ONE SINGLE line.V560 A part of conditional expression is always false: 0. clist_modern modern_clui.cpp 2979LRESULT CLUI::OnDrawItem( UINT msg, WPARAM wParam, LPARAM lParam ){ ... DrawState(dis->hDC,NULL,NULL,(LPARAM)hIcon,0, dis->rcItem.right+dis->rcItem.left- GetSystemMetrics(SM_CXSMICON))/2+dx, (dis->rcItem.bottom+dis->
  9. 9. GetSystemMetrics(SM_CYSMICON))/2+dx, 0,0, DST_ICON| (dis->itemState&ODS_INACTIVE&&FALSE?DSS_DISABLED:DSS_NORMAL)); ...}If there is no error here, still it is hard to remember and find the word FALSE in this line. Have you foundit? So, it is a difficult task, isnt it? And what if there is an error? You have no chances to find it by justreviewing the code. Such expressions should be arranged as a separate line. For example:UINT uFlags = DST_ICON;uFlags |= dis->itemState & ODS_INACTIVE && FALSE ? DSS_DISABLED : DSS_NORMAL;Personally I would make this code longer yet clearer:UINT uFlags;if (dis->itemState & ODS_INACTIVE && (((FALSE)))) uFlags = DST_ICON | DSS_DISABLED;else uFlags = DST_ICON | DSS_NORMAL;Yes, this sample is longer but it is well readable and the word FALSE is well noticeable.4. Align everything you can in codeCode alignment makes it less probable that you will misprint or make a mistake using Copy-Paste. If youstill make an error, it will be much easier to find it during code review. Lets examine a code sample.V537 Consider reviewing the correctness of maxX items usage. clist_modern modern_skinengine.cpp2898static BOOL ske_DrawTextEffect(...){ ... minX=max(0,minX+mcLeftStart-2); minY=max(0,minY+mcTopStart-2); maxX=min((int)width,maxX+mcRightEnd-1);
  10. 10. maxY=min((int)height,maxX+mcBottomEnd-1); ...}It is just a solid code fragment and it is not interesting to read it at all. Lets edit it:minX = max(0, minX + mcLeftStart - 2);minY = max(0, minY + mcTopStart - 2);maxX = min((int)width, maxX + mcRightEnd - 1);maxY = min((int)height, maxX + mcBottomEnd - 1);This is not the most typical example but you agree that it is much easier to notice now that the maxXvariable is used twice, dont you?Do not take my recommendation on alignment literally writing columns of code everywhere. First, itrequires some time when writing and editing code. Second, it may cause other errors. In the nextsample you will see how that very wish to make a nice column caused an error in Miranda IMs code.V536 Be advised that the utilized constant value is represented by an octal form. Oct: 037, Dec: 31. msnmsn_mime.cpp 192static const struct _tag_cpltbl{ unsigned cp; const char* mimecp;} cptbl[] ={ { 037, "IBM037" }, // IBM EBCDIC US-Canada { 437, "IBM437" }, // OEM United States { 500, "IBM500" }, // IBM EBCDIC International { 708, "ASMO-708" }, // Arabic (ASMO 708) ...}Trying to make a nice column of numbers, you might be easily carried away and write 0 in thebeginning making the constant an octal number.So I define my recommendation more exactly: align everything you can in code, but do not alignnumbers by writing zeroes.
  11. 11. 5. Do not copy a line more than onceCopying lines in programming is inevitable. But you may secure yourself by giving up on inserting a linefrom the clipboard several times at once. In most cases, youd better copy a line and then edit it. Thenagain copy a line and edit it. And so on. If you do so, it is much harder to forget to change something in aline or change it wrongly. Lets examine a code sample:V525 The code containing the collection of similar blocks. Check items 1316, 1319, 1318, 1323,1323, 1317, 1321 in lines 954, 955, 956, 957, 958, 959, 960. clist_modern modern_clcopts.cpp 954static INT_PTR CALLBACK DlgProcTrayOpts(...){ ... EnableWindow(GetDlgItem(hwndDlg,IDC_PRIMARYSTATUS),TRUE); EnableWindow(GetDlgItem(hwndDlg,IDC_CYCLETIMESPIN),FALSE); EnableWindow(GetDlgItem(hwndDlg,IDC_CYCLETIME),FALSE); EnableWindow(GetDlgItem(hwndDlg,IDC_ALWAYSPRIMARY),FALSE); EnableWindow(GetDlgItem(hwndDlg,IDC_ALWAYSPRIMARY),FALSE); EnableWindow(GetDlgItem(hwndDlg,IDC_CYCLE),FALSE); EnableWindow(GetDlgItem(hwndDlg,IDC_MULTITRAY),FALSE); ...}Most likely, there is no real error here; we just handle the item IDC_ALWAYSPRIMARY twice. However,you may easily make an error in such blocks of copied-pasted lines.6. Set a high warning level of your compiler and use static analyzersFor many errors, there are no recommendations to give on how to avoid them. They are most oftenmisprints both novices and skillful programmers make.However, many of these errors can be detected at the stage of code writing already. First of all with thehelp of the compiler. And then with the help of static code analyzers reports after night runs.Someone would say now that it is a scarcely concealed advertising. But actually it is just anotherrecommendation that will help you to have fewer errors. If I have found errors using static analysis andcannot say how to avoid them in code, it means that using static code analyzers is just that veryrecommendation.Now lets examine some samples of errors that may be quickly detected by static code analyzers:
  12. 12. V560 A part of conditional expression is always true: 0x01000. tabsrmm tools.cpp 1023#define GC_UNICODE 0x01000DWORD dwFlags;UINT CreateGCMenu(...){ ... if (iIndex == 1 && si->iType != GCW_SERVER && !(si->dwFlags && GC_UNICODE)) { ...}We have a misprint here: the && operator is used instead of & operator. I do not know how one couldsecure oneself against this error while writing code. This is the correct condition:(si->dwFlags & GC_UNICODE)The next sample.V528 It is odd that pointer to char type is compared with the 0 value. Probably meant: *str != 0.clist_modern modern_skinbutton.cpp 282V528 It is odd that pointer to char type is compared with the 0 value. Probably meant: *endstr !=0. clist_modern modern_skinbutton.cpp 283static char *_skipblank(char * str){ char * endstr=str+strlen(str); while ((*str== || *str==t) && str!=0) str++; while ((*endstr== || *endstr==t) && endstr!=0 && endstr<str) endstr--; ...
  13. 13. }The programmer just missed two asterisks * for pointer dereferencing operations. The result might bea fatal one. This code is prone to violation access errors. This is the correct code:while ((*str== || *str==t) && *str!=0) str++;while ((*endstr== || *endstr==t) && *endstr!=0 && endstr<str) endstr--;Again I cannot give any particular tip except using special tools for code check.The next sample.V514 Dividing sizeof a pointer sizeof (text) by another value. There is a probability of logical errorpresence. clist_modern modern_cachefuncs.cpp 567#define SIZEOF(X) (sizeof(X)/sizeof(X[0]))int Cache_GetLineText(..., LPTSTR text, int text_size, ...){ ... tmi.printDateTime(pdnce->hTimeZone, _T("t"), text, SIZEOF(text), 0); ...}Everything is OK at first sight. The text and its length which is calculated with the SIZEOF macro arepassed into the function. Actually this macro must be called COUNT_OF, but thats not the point. Thepoint is that we are trying to calculate the number of characters in the pointer. It is "sizeof(LPTSTR) /sizeof(TCHAR)" which is calculated here. A human hardly notices such fragments but compiler and staticanalyzer see them well. This is the corrected code:tmi.printDateTime(pdnce->hTimeZone, _T("t"), text, text_size, 0);The next sampleV560 A part of conditional expression is always true: 0x29. icqoscar8 fam_03buddy.cpp 632
  14. 14. void CIcqProto::handleUserOffline(BYTE *buf, WORD wLen){ ... else if (wTLVType = 0x29 && wTLVLen == sizeof(DWORD)) ...}In such cases, I recommend you to write a constant first in the condition. The following code will simplynot compile:if (0x29 = wTLVType && sizeof(DWORD) == wTLVLen)But many programmers, including myself, do not like this style. For instance, personally I get confusedbecause I want to know first what variable is being compared and only then - to what it is beingcompared.If the programmer does not want to use this comparison style, he has either to rely oncompiler/analyzer or risk.By the way, this error is not a rare one despite being widely known among programmers. Here are threemore examples from Miranda IM where the PVS-Studio analyzer generated the V559 warning:else if (ft->ft_magic = FT_MAGIC_OSCAR)if (ret=0) {return (0);}if (Drawing->type=CLCIT_CONTACT)The code analyzer also allows you to detect very suspicious places in code, if not errors. For instance,pointers serve not only as pointers in Miranda IM. In some places such games look fine, in other placesthey look scary. Here is a code sample that alerts me:V542 Consider inspecting an odd type cast: char * to char. clist_modern modern_toolbar.cpp 586static voidsttRegisterToolBarButton(..., char * pszButtonName, ...){ ... if ((BYTE)pszButtonName)
  15. 15. tbb.tbbFlags=TBBF_FLEXSIZESEPARATOR; else tbb.tbbFlags=TBBF_ISSEPARATOR; ...}Actually we are checking here if the strings address is not equal to 256. I do not quite understand whatthe developers intended to write in this condition. Perhaps this fragment is even correct but I doubt it.You may find a lot of incorrect conditions using code analysis. For example:V501 There are identical sub-expressions user->statusMessage to the left and to the right of the &&operator. jabber jabber_chat.cpp 214void CJabberProto::GcLogShowInformation(...){ ... if (user->statusMessage && user->statusMessage) ...}And so on and so forth. I can give your other examples, a lot of them. But there is no reason. The mainpoint is that you may detect many errors with static analysis at the very early stages.When a static analyzer finds few errors in your program, it does not seem interesting to use it. But this isa wrong conclusion. You see, you paid with blood and sweat and spent hours on debugging andcorrecting errors which analyzer could have found at early stages.Static analysis is of large interest in the software development field and not as a tool for one-timechecks. Many errors and misprints are detected during testing and unit-test development. But if youmanage to find some of them at the stage of code writing already, you will have a great time and effortgain. It is a pity when you debug a program for two hours just to notice an unnecessary semicolon ; after the for operator. Usually you may get rid of this error by spending 10 minutes on static analysis offiles that have been changed during development process.SummaryIn this article, I have shared only some of my ideas concerning ways of avoiding as many errors aspossible in C++ programming. There are some other ideas I am pondering on. I will try to write aboutthem in the next articles and posts.
  16. 16. P.S.It has become a tradition to ask, after reading such an article, if we have told the applications/librarysdevelopers about the errors found. I will answer beforehand to a probable question if we have sent thebug report to Miranda IMs developers.No, we have not. This task is too resource-intensive. We have showed only a small part of what wefound in the project. There are about a hundred fragments in it about which I cannot say exactly if theyare errors or not. However, we will send this article to Miranda IMs authors and offer them a freeversion of the PVS-Studio analyzer. If theyll get interested in the subject, they will check their sourcecode themselves and fix whatever they consider necessary to fix.I must also clarify why I often cannot say exactly if a particular code fragment has an error. This is asample of ambiguous code:V523 The then statement is equivalent to the else statement. scriver msglog.c 695if ( streamData->isFirst ) { if (event->dwFlags & IEEDF_RTL) { AppendToBuffer(&buffer, &bufferEnd, &bufferAlloced, "rtlpar"); } else { AppendToBuffer(&buffer, &bufferEnd, &bufferAlloced, "ltrpar"); }} else { if (event->dwFlags & IEEDF_RTL) { AppendToBuffer(&buffer, &bufferEnd, &bufferAlloced, "rtlpar"); } else { AppendToBuffer(&buffer, &bufferEnd, &bufferAlloced, "ltrpar"); }}Here you are two identical code fragments. Perhaps it is an error. Or maybe the programmer needs tohave two identical action sets in every branch, so he has written the code so that it could be easilymodified later. You need to know the program to make out if this place is a mistake or not.