लिबर ऑफिस: अकाउंटेंट के बुरे सपने

लिब्रे ऑफिस एक शक्तिशाली कार्यालय सुइट है जो निजी, शैक्षिक और व्यावसायिक उपयोग के लिए निःशुल्क है। इसके डेवलपर्स एक अद्भुत उत्पाद बना रहे हैं, जिसका उपयोग कई क्षेत्रों में माइक्रोसॉफ्ट ऑफिस के विकल्प के रूप में किया जाता है। पीवीएस-स्टूडियो टीम हमेशा ऐसी प्रसिद्ध परियोजनाओं के कोड को देखने और उनमें त्रुटियों को खोजने की कोशिश करने में रुचि रखती है। इस बार करना आसान था। परियोजना में कई त्रुटियां हैं जो गंभीर समस्याएं पैदा कर सकती हैं। लेख कोड में पाए जाने वाले कुछ दिलचस्प दोषों पर चर्चा करेगा।

परिचय

लिब्रे ऑफिस एक बहुत बड़ी C ++ परियोजना है। इस आकार की एक परियोजना को बनाए रखना विकास टीम के लिए एक मुश्किल काम है। और, दुर्भाग्य से, किसी को यह धारणा मिलती है कि लिबरऑफिस कोड की गुणवत्ता पर्याप्त ध्यान देने में विफल रहती है।

एक तरफ, परियोजना बस विशाल है, न कि प्रत्येक स्थिर या गतिशील विश्लेषण उपकरण 13k स्रोत कोड फ़ाइलों के विश्लेषण को संभाल सकता है। कई फाइलें तीसरे पक्ष के पुस्तकालयों के साथ कार्यालय सुइट के निर्माण में शामिल हैं। मुख्य LibreOffice भंडार भंडार 8k स्रोत कोड फ़ाइलों के बारे में है। कोड की यह राशि न केवल डेवलपर्स के लिए समस्याएं पैदा करती है:

दूसरी ओर, परियोजना में कई उपयोगकर्ता हैं और जितनी संभव हो उतने त्रुटियों को खोजने और ठीक करने की आवश्यकता है। हर गलती सैकड़ों और हजारों उपयोगकर्ताओं को चोट पहुंचा सकती है। इसलिए, कोड आधार का बड़ा आकार कुछ उपकरणों का उपयोग करने से इनकार करने का बहाना नहीं बनना चाहिए जो त्रुटियों का पता लगा सकते हैं। मुझे लगता है कि पाठक पहले ही अनुमान लगा चुके हैं कि हम स्टैटिक कोड एनालाइज़र :) के बारे में बात कर रहे हैं।

हां, स्थैतिक विश्लेषणकर्ताओं का उपयोग परियोजना में त्रुटियों की अनुपस्थिति की गारंटी नहीं देता है। हालांकि, पीवीएस-स्टूडियो जैसे उपकरण विकास के स्तर पर बड़ी संख्या में त्रुटियों को खोजने में सक्षम हैं और इस तरह डिबगिंग और परियोजना समर्थन से जुड़े काम की मात्रा को कम करते हैं।

आइए देखें कि यदि आप पीवीएस-स्टूडियो स्टैटिक कोड एनालाइजर लेते हैं तो लिबरऑफिस सोर्स कोड में आपको क्या दिलचस्प मिल सकता है। विश्लेषक चलाने के लिए संभावनाएं व्यापक हैं: विंडोज, लिनक्स, मैकओएस। इस समीक्षा को लिखने के लिए, पीवीएस-स्टूडियो रिपोर्ट का उपयोग किया गया था, जिसे विंडोज पर परियोजना के विश्लेषण के दौरान बनाया गया था।

2015 में अंतिम जांच के बाद से परिवर्तन

मार्च 2015 में, PVS-Studio का उपयोग करके LibreOffice (" LibreOffice प्रोजेक्ट का सत्यापन ") का पहला विश्लेषण किया गया था। तब से, कार्यालय सूट एक उत्पाद के रूप में बहुत विकसित हुआ है, लेकिन इसके अंदर भी कई त्रुटियां हैं। और कुछ त्रुटि पैटर्न तब से बिल्कुल भी नहीं बदले हैं। यहाँ, उदाहरण के लिए, पहले लेख से एक गलती है:

V656 वेरिएबल्स 'एवीआरपी', 'एवीपीएन' को एक ही फ़ंक्शन के लिए कॉल के माध्यम से प्रारंभ किया जाता है। यह शायद एक त्रुटि या अन-अनुकूलित कोड है। 'RSceneCamera.GetVRP ()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। चेक लाइन: 177, 178। viewcontactofe3dscene.cxx 178

void ViewContactOfE3dScene::createViewInformation3D(....) { .... const basegfx::B3DPoint aVRP(rSceneCamera.GetVRP()); const basegfx::B3DVector aVPN(rSceneCamera.GetVRP()); // <= const basegfx::B3DVector aVUV(rSceneCamera.GetVUV()); .... } 

यह बग ठीक कर दिया गया है, लेकिन यहां वह है जो कोड के नवीनतम संस्करण में पाया गया था:

V656 वेरिएबल्स 'aSdvURL', 'aStrURL' को एक ही फ़ंक्शन के लिए कॉल के माध्यम से प्रारंभ किया जाता है। यह शायद एक त्रुटि या अन-अनुकूलित कोड है। 'PThm-> GetSdvURL ()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। चेक लाइनें: 658, 659. गैलरी 1। सीएक्स 659

 const INetURLObject& GetThmURL() const { return aThmURL; } const INetURLObject& GetSdgURL() const { return aSdgURL; } const INetURLObject& GetSdvURL() const { return aSdvURL; } const INetURLObject& GetStrURL() const { return aStrURL; } bool Gallery::RemoveTheme( const OUString& rThemeName ) { .... INetURLObject aThmURL( pThm->GetThmURL() ); INetURLObject aSdgURL( pThm->GetSdgURL() ); INetURLObject aSdvURL( pThm->GetSdvURL() ); INetURLObject aStrURL( pThm->GetSdvURL() ); // <= .... } 

जैसा कि आपने देखा होगा, सूक्ष्म यौगिक फ़ंक्शन नाम अभी भी त्रुटियों का एक स्रोत हैं।

पुराने कोड से एक और दिलचस्प उदाहरण:

V656 वेरिएबल्स 'nDragW', 'nDragH' को एक ही फ़ंक्शन के लिए कॉल के माध्यम से प्रारंभ किया जाता है। यह शायद एक त्रुटि या अन-अनुकूलित कोड है। 'RMSettings.GetStartDragWidth ()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। चेक लाइनें: 471, 472. winproc.cxx 472

 class VCL_DLLPUBLIC MouseSettings { .... long GetStartDragWidth() const; long GetStartDragHeight() const; .... } bool ImplHandleMouseEvent( .... ) { .... long nDragW = rMSettings.GetStartDragWidth(); long nDragH = rMSettings.GetStartDragWidth(); .... } 

कोड के इस टुकड़े में वास्तव में एक बग था जो अब तय हो गया है। लेकिन कोड में त्रुटियां छोटी नहीं हो रही हैं ... एक समान स्थिति अब पहचान ली गई है:

V656 वेरिएबल्स 'defaultZoomX', 'defaultZoomY' को एक ही फ़ंक्शन के लिए कॉल के माध्यम से आरंभ किया जाता है। यह शायद एक त्रुटि या अन-अनुकूलित कोड है। 'PViewData-> GetZoomX ()' अभिव्यक्ति का निरीक्षण करने पर विचार करें। चेक लाइनें: 5673, 5674. ग्रिडविन.कॉइन 5674

 OString ScGridWindow::getCellCursor(....) const { .... SCCOL nX = pViewData->GetCurX(); SCROW nY = pViewData->GetCurY(); Fraction defaultZoomX = pViewData->GetZoomX(); Fraction defaultZoomY = pViewData->GetZoomX(); // <= .... } 

त्रुटियों को सादृश्य द्वारा शाब्दिक रूप से कोड में पेश किया जाता है।

मूर्ख मत बनो

V765 एक यौगिक असाइनमेंट अभिव्यक्ति 'x - = x - ...' संदेहास्पद है। संभावित त्रुटि के लिए इसका निरीक्षण करने पर विचार करें। swdtflvr.cxx 3509

 bool SwTransferable::PrivateDrop(...) { .... if ( rSrcSh.IsSelFrameMode() ) { //Hack: fool the special treatment aSttPt -= aSttPt - rSrcSh.GetObjRect().Pos(); } .... } 

यहाँ इस तरह के एक दिलचस्प "हैक" को V765 नैदानिक ​​का उपयोग करके पाया गया था। यदि आप एक टिप्पणी के साथ कोड की एक पंक्ति को सरल करते हैं, तो आप एक अप्रत्याशित परिणाम प्राप्त कर सकते हैं:

पहला चरण:

 aSttPt = aSttPt - (aSttPt - rSrcSh.GetObjRect().Pos()); 

दूसरा चरण:

 aSttPt = aSttPt - aSttPt + rSrcSh.GetObjRect().Pos(); 

तीसरा चरण

 aSttPt = rSrcSh.GetObjRect().Pos(); 

और फिर हैक क्या है?

इस विषय पर एक और उदाहरण:

V567 'nCount' वैरिएबल का संशोधन उसी वैरिएबल पर एक अन्य ऑपरेशन के सापेक्ष अप्रयुक्त है। इससे अपरिभाषित व्यवहार हो सकता है। stgio.cxx 214

 FatError EasyFat::Mark(....) { if( nCount > 0 ) { --nCount /= GetPageSize(); nCount++; } .... } 

ऐसी स्थितियों में कोड निष्पादन संकलक और भाषा मानक पर निर्भर हो सकता है। सरल, स्पष्ट और अधिक विश्वसनीय तरीके से इस कोड स्निपेट को फिर से क्यों नहीं लिखा जाए?

कैसे सरणियों और वैक्टर का उपयोग करने के लिए नहीं

किसी कारण से, किसी ने सरणियों और वैक्टर के साथ काम करते समय बहुत सी समान त्रुटियां कीं। आइए इन उदाहरणों को देखें।

V557 ऐरे ओवररन संभव है। 'NPageNum' सूचकांक सरणी बाउंड से परे इंगित कर रहा है। pptx-epptooxml.cxx 1168

 void PowerPointExport::ImplWriteNotes(sal_uInt32 nPageNum) { .... // add slide implicit relation to notes if (mpSlidesFSArray.size() >= nPageNum) addRelation(mpSlidesFSArray[ nPageNum ]->getOutputStream(), oox::getRelationship(Relationship::NOTESSLIDE), OUStringBuffer() .append("../notesSlides/notesSlide") .append(static_cast<sal_Int32>(nPageNum) + 1) .append(".xml") .makeStringAndClear()); .... } 

अंतिम वैध सूचकांक आकार के बराबर मूल्य () - 1 होना चाहिए। लेकिन इस कोड के टुकड़े में, ऐसी स्थिति की अनुमति दी गई थी जब nPageNum इंडेक्स में mpSlidesFSArray.size () मान हो सकता है, क्योंकि इसमें आउट-ऑफ- बाउंड्स सरणी है और "कचरा" वाले तत्व के साथ काम करते हैं।

V557 ऐरे ओवररन संभव है। 'MnSelectedMenu' सूचकांक सरणी बाउंड से परे इंगित कर रहा है। checklistmenu.cxx 826

 void ScMenuFloatingWindow::ensureSubMenuNotVisible() { if (mnSelectedMenu <= maMenuItems.size() && maMenuItems[mnSelectedMenu].mpSubMenuWin && maMenuItems[mnSelectedMenu].mpSubMenuWin->IsVisible()) { maMenuItems[mnSelectedMenu].mpSubMenuWin->ensureSubMenuNotVisible(); } EndPopupMode(); } 

दिलचस्प है, इस कोड के टुकड़े में उन्होंने एक इंडेक्स चेक अधिक स्पष्ट रूप से लिखा था, लेकिन एक ही समय में एक ही गलती की।

V557 ऐरे ओवररन संभव है। 'NXFIndex' सूचकांक सरणी बाउंड से परे इंगित कर रहा है। xestyle.cxx 2613

 sal_Int32 XclExpXFBuffer::GetXmlStyleIndex( sal_uInt32 nXFIndex ) const { OSL_ENSURE( nXFIndex < maStyleIndexes.size(), "...." ); if( nXFIndex > maStyleIndexes.size() ) return 0; // should be caught/debugged via above assert; return maStyleIndexes[ nXFIndex ]; } 

और यह गलती दोगुनी दिलचस्प है! डीबगिंग मैक्रो में, उन्होंने सही इंडेक्स चेक लिखा, और दूसरी जगह उन्होंने फिर से एक गलती की, जिससे उन्हें सरणी के बाहर जाने की अनुमति मिली।

अब एक अलग तरह की त्रुटि पर विचार करें जो अनुक्रमणिका से संबंधित नहीं है।

V554 Share_ptr का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। dx_vcltools.cxx 158

 struct RawRGBABitmap { sal_Int32 mnWidth; sal_Int32 mnHeight; std::shared_ptr< sal_uInt8 > mpBitmapData; }; RawRGBABitmap bitmapFromVCLBitmapEx( const ::BitmapEx& rBmpEx ) { .... // convert transparent bitmap to 32bit RGBA // ======================================== const ::Size aBmpSize( rBmpEx.GetSizePixel() ); RawRGBABitmap aBmpData; aBmpData.mnWidth = aBmpSize.Width(); aBmpData.mnHeight = aBmpSize.Height(); aBmpData.mpBitmapData.reset( new sal_uInt8[ 4*aBmpData.mnWidth *aBmpData.mnHeight ] ); .... } 

कोड के इस टुकड़े में एक अपरिभाषित कार्यक्रम व्यवहार के लिए अग्रणी त्रुटि है। तथ्य यह है कि स्मृति को अलग-अलग तरीकों से आवंटित और मुक्त किया जाता है। मेमोरी को ठीक से मुक्त करने के लिए, आपको इस तरह एक क्लास फील्ड घोषित करना होगा:

 std::shared_ptr< sal_uInt8[] > mpBitmapData; 

मैक्रोज़ को दो बार कैसे बनाएं

V568 यह अजीब है कि आकार का तर्क () ऑपरेटर 'bTextFrame' है? aProps: aShapeProps की अभिव्यक्ति। wpscontext.cxx 134

 oox::core::ContextHandlerRef WpsContext::onCreateContext(....) { .... OUString aProps[] = { .... }; OUString aShapeProps[] = { .... }; for (std::size_t i = 0; i < SAL_N_ELEMENTS(bTextFrame ? aProps : aShapeProps); //1 ++i) if (oInsets[i]) xPropertySet->setPropertyValue((bTextFrame ? aProps : aShapeProps)[i], //2 uno::makeAny(*oInsets[i])); .... } 

दुर्भाग्य से कई डेवलपर्स के लिए, मैक्रो तर्कों में फ़ंक्शन तर्कों की तरह व्यवहार नहीं किया जाता है। इस तथ्य को अनदेखा करना अक्सर त्रुटियों की ओर जाता है। # 1 और # 2 के मामलों में, लगभग समान निर्माण का उपयोग टर्नरी ऑपरेटर द्वारा किया जाता है। लेकिन पहले मामले में - एक मैक्रो, दूसरे में - एक फ़ंक्शन। हालाँकि, यह केवल समस्या का शीर्ष है।

# 1 के मामले में, विश्लेषक ने वास्तव में निम्नलिखित त्रुटि कोड का पता लगाया:

 for (std::size_t i = 0; i < (sizeof (bTextFrame ? aProps : aShapeProps) / sizeof ((bTextFrame ? aProps : aShapeProps)[0])); ++i) 

यह SAL_N_ELEMENTS मैक्रो के साथ हमारा लूप है। आकारऑपर ऑपरेटर टर्नेरी ऑपरेटर में अभिव्यक्ति का मूल्यांकन नहीं करता है। इस मामले में, अंक के आकार के साथ अंकगणित किया जाता है, जिसके परिणाम वे मान होते हैं जो इंगित किए गए सरणियों के वास्तविक आकार से दूर होते हैं। गलत मानों की गणना एप्लिकेशन की थोड़ी गहराई से अतिरिक्त रूप से प्रभावित होती है।

लेकिन फिर यह पता चला कि 2 SAL_N_ELEMENTS मैक्रोज़ हैं! यानी प्रीप्रोसेसर ने गलत मैक्रो को खोला, यह कैसे हो सकता है? मैक्रो डेफिनिशन और डेवलपर कमेंट्स हमारी मदद करेंगे:

 #ifndef SAL_N_ELEMENTS # if defined(__cplusplus) && ( defined(__GXX_EXPERIMENTAL_CXX0X__) || __cplusplus >= 201103L ) /* * Magic template to calculate at compile time the number of elements * in an array. Enforcing that the argument must be a array and not * a pointer, eg * char *pFoo="foo"; * SAL_N_ELEMENTS(pFoo); * fails while * SAL_N_ELEMENTS("foo"); * or * char aFoo[]="foo"; * SAL_N_ELEMENTS(aFoo); * pass * * Unfortunately if arr is an array of an anonymous class then we need * C++0x, ie see * http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#757 */ template <typename T, size_t S> char (&sal_n_array_size( T(&)[S] ))[S]; # define SAL_N_ELEMENTS(arr) (sizeof(sal_n_array_size(arr))) # else # define SAL_N_ELEMENTS(arr) (sizeof (arr) / sizeof ((arr)[0])) # endif #endif 

मैक्रो के एक अन्य संस्करण में एक सुरक्षित टेम्पलेट फ़ंक्शन होता है, लेकिन कुछ गलत हो गया:

1. सुरक्षित मैक्रो कोड में शामिल नहीं था;
2. एक और मैक्रो का उपयोग करना अभी भी असंभव है, क्योंकि टेम्पलेट फ़ंक्शन के सफल तात्कालिकता का प्रदर्शन केवल तभी किया जाता है जब समान आकार के सरणियों को टर्नरी ऑपरेटर को स्थानांतरित किया जाता है। और इस मामले में इस तरह के मैक्रो का उपयोग इसके अर्थ को खो देता है।

टाइपो और कॉपी-पेस्ट

V1013 समान उप-अनुक्रम के अनुक्रम में संदिग्ध उपसंचाई f1.Pitch == f2.CharSet। xmldlg_export.cxx 1251

 inline bool equalFont( Style const & style1, Style const & style2 ) { awt::FontDescriptor const & f1 = style1._descr; awt::FontDescriptor const & f2 = style2._descr; return ( f1.Name == f2.Name && f1.Height == f2.Height && f1.Width == f2.Width && f1.StyleName == f2.StyleName && f1.Family == f2.Family && f1.CharSet == f2.CharSet && // <= f1.Pitch == f2.CharSet && // <= f1.CharacterWidth == f2.CharacterWidth && f1.Weight == f2.Weight && f1.Slant == f2.Slant && f1.Underline == f2.Underline && f1.Strikeout == f2.Strikeout && f1.Orientation == f2.Orientation && bool(f1.Kerning) == bool(f2.Kerning) && bool(f1.WordLineMode) == bool(f2.WordLineMode) && f1.Type == f2.Type && style1._fontRelief == style2._fontRelief && style1._fontEmphasisMark == style2._fontEmphasisMark ); } 

यदि हम कभी भी इसे अपडेट करने या विस्तारित करने का निर्णय लेते हैं, तो त्रुटि "योग्य कार्यों में बुराई रहती है " लेख को अपडेट करने के लिए एक योग्य उम्मीदवार है। मुझे लगता है कि इस तरह की त्रुटि (पास f2.Pitch ) अकेले होने की संभावना बेहद कम है। आपको क्या लगता है?

V501 समान उप-अभिव्यक्तियाँ हैं 'mpTable [ocArrayColSep]! = MpTable [eOp]' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। formulacompiler.cxx 632

 void FormulaCompiler::OpCodeMap::putOpCode(....) { .... case ocSep: bPutOp = true; bRemoveFromMap = (mpTable[eOp] != ";" && mpTable[ocArrayColSep] != mpTable[eOp] && mpTable[ocArrayColSep] != mpTable[eOp]); break; .... } 

विचारहीन नकल का परिणाम कोड का यह टुकड़ा था। शायद सशर्त अभिव्यक्ति बस एक बार फिर से दोहराई जाती है, लेकिन अभी भी कोड में ऐसी अस्पष्टताओं के लिए कोई जगह नहीं है।

V517 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइनें: 781, 783. mysqlc_databasemetadata.cxx 781

 Reference<XResultSet> SAL_CALL ODatabaseMetaData::getColumns(....) { .... bool bIsCharMax = !xRow->wasNull(); if (sDataType.equalsIgnoreAsciiCase("year")) nColumnSize = sColumnType.copy(6, 1).toInt32(); else if (sDataType.equalsIgnoreAsciiCase("date")) // <= nColumnSize = 10; else if (sDataType.equalsIgnoreAsciiCase("date")) // <= nColumnSize = 8; else if (sDataType.equalsIgnoreAsciiCase("datetime") || sDataType.equalsIgnoreAsciiCase("timestamp")) nColumnSize = 19; else if (!bIsCharMax) nColumnSize = xRow->getShort(7); else nColumnSize = nCharMaxLen; .... } 

सशर्त अभिव्यक्तियों की नकल करने के परिणामस्वरूप, कोड में एक त्रुटि हुई, जिसके कारण चर nColumnSize के लिए मान 8 कभी सेट नहीं किया गया है।

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। svdpdf.hxx 146

 /// Transform the rectangle (left, right, top, bottom) by this Matrix. template <typename T> void Transform(....) { .... if (top > bottom) top = std::max(leftTopY, rightTopY); else top = std::min(leftTopY, rightTopY); if (top > bottom) bottom = std::max(leftBottomY, rightBottomY); // <= else bottom = std::max(leftBottomY, rightBottomY); // <= } 

यहां फ़ंक्शंस मिन () और अधिकतम () उलझन में हैं। निश्चित रूप से, इंटरफ़ेस में इस टाइपो के कारण, कुछ अजीब रूप से छोटा है।

अजीब सा चक्र

V533 यह संभावना है कि 'के लिए' ऑपरेटर के अंदर एक गलत परिवर्तन किया जा रहा है। 'I' की समीक्षा करने पर विचार करें। javatypemaker.cxx 602

 void printConstructors(....) { .... for (std::vector< unoidl::SingleInterfaceBasedServiceEntity::Constructor:: Parameter >::const_iterator j(i->parameters.begin()); j != i->parameters.end(); ++i) { o << ", "; printType(o, options, manager, j->type, false); if (j->rest) { o << "..."; } o << ' ' << codemaker::java::translateUnoToJavaIdentifier( u2b(j->name), "param"); } .... } 

लूप में अभिव्यक्ति ++ i बहुत संदिग्ध दिखता है। हो सकता है कि वहां ++ j होना चाहिए।

V756 'nIndex2' काउंटर का उपयोग नेस्टेड लूप के अंदर नहीं किया जाता है। 'निंडेक्स' काउंटर के निरीक्षण के उपयोग पर विचार करें। Treex.cxx 34

 SAL_IMPLEMENT_MAIN_WITH_ARGS(argc, argv) { OString sXHPRoot; for (int nIndex = 1; nIndex != argc; ++nIndex) { if (std::strcmp(argv[nIndex], "-r") == 0) { sXHPRoot = OString( argv[nIndex + 1] ); for( int nIndex2 = nIndex+3; nIndex2 < argc; nIndex2 = nIndex2 + 2 ) { argv[nIndex-3] = argv[nIndex-1]; argv[nIndex-2] = argv[nIndex]; } argc = argc - 2; break; } } common::HandledArgs aArgs; if( !common::handleArguments(argc, argv, aArgs) ) { WriteUsage(); return 1; } .... } 

लूप के लिए आंतरिक में किसी प्रकार की त्रुटि है। क्योंकि n nndex वैरिएबल परिवर्तित नहीं होता है; सरणी के समान दो तत्व प्रत्येक पुनरावृत्ति पर ओवरराइट किए जाते हैं। सबसे अधिक संभावना है, nIndex के बजाय, हर जगह चर nIndex2 का उपयोग किया जाना चाहिए था।

V1008 'ऑपरेटर' के लिए निरीक्षण करने पर विचार करें। लूप का एक से अधिक पुनरावृत्ति नहीं किया जाएगा। diagramhelper.cxx 292

 void DiagramHelper::setStackMode( const Reference< XDiagram > & xDiagram, StackMode eStackMode ) { .... sal_Int32 nMax = aChartTypeList.getLength(); if( nMax >= 1 ) nMax = 1; for( sal_Int32 nT = 0; nT < nMax; ++nT ) { uno::Reference< XChartType > xChartType( aChartTypeList[nT] ); .... } .... } 

लूप के लिए जानबूझकर 1 पुनरावृत्ति तक सीमित है। यह स्पष्ट नहीं है कि ऐसा क्यों किया जाता है।

V612 एक लूप के भीतर बिना शर्त 'वापसी'। pormulti.cxx 891

 SwTextAttr const* MergedAttrIterMulti::NextAttr(....) { .... SwpHints const*const pHints(m_pNode->GetpSwpHints()); if (pHints) { while (m_CurrentHint < pHints->Count()) { SwTextAttr const*const pHint(pHints->Get(m_CurrentHint)); ++m_CurrentHint; rpNode = m_pNode; return pHint; } } return nullptr; .... } 

एक पुनरावृत्ति से एक सरल अजीब लूप का एक उदाहरण, जो सशर्त बयान को फिर से लिखना बेहतर है।

ऐसी ही कुछ और जगहें:

• V612 एक लूप के भीतर बिना शर्त 'वापसी'। txtfrm.cxx 144
• V612 एक लूप के भीतर बिना शर्त 'वापसी'। txtfrm.cxx 202
• V612 एक लूप के भीतर बिना शर्त 'वापसी'। txtfrm.cxx 279

अजीब स्थिति है

V637 दो विपरीत परिस्थितियों का सामना करना पड़ा। दूसरी स्थिति हमेशा झूठी होती है। चेक लाइन्स: 281, 285। Cortfld.cxx 281

 sal_uInt16 SwAuthorityFieldType::GetSequencePos(sal_IntPtr nHandle) { .... SwTOXSortTabBase* pOld = aSortArr[i].get(); if(*pOld == *pNew) { //only the first occurrence in the document //has to be in the array if(*pOld < *pNew) pNew.reset(); else // remove the old content aSortArr.erase(aSortArr.begin() + i); break; } .... } 

विश्लेषक ने परस्पर विरोधी तुलनाएं पाईं। कोड के इस टुकड़े के साथ कुछ स्पष्ट रूप से गलत है।

इस स्थान पर समान कोड देखा गया है:

• V637 दो विपरीत परिस्थितियों का सामना करना पड़ा। दूसरी स्थिति हमेशा झूठी होती है। चेक लाइनें: 1827, 1829. doctxm.cxx 1827

V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। fileurl.cxx 55

 OUString convertToFileUrl(char const * filename, ....) { .... if ((filename[0] == '.') || (filename[0] != SEPARATOR)) { .... } .... } 

उपरोक्त कोड के टुकड़े के साथ समस्या यह है कि पहली सशर्त अभिव्यक्ति पूरे अभिव्यक्ति के परिणाम को प्रभावित नहीं करती है।

इस तरह की त्रुटियों के आधार पर, मैंने एक सैद्धांतिक लेख भी लिखा: " सी / सी ++ में तार्किक भाव। पेशेवर कैसे गलत होते हैं ।"

V590 इस अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। unoobj.cxx 1895

 uno::Sequence< beans::PropertyState > SwUnoCursorHelper::GetPropertyStates(....) { .... if (((SW_PROPERTY_STATE_CALLER_SWX_TEXT_PORTION == eCaller) || (SW_PROPERTY_STATE_CALLER_SWX_TEXT_PORTION_TOLERANT == eCaller)) && pEntry->nWID < FN_UNO_RANGE_BEGIN && pEntry->nWID > FN_UNO_RANGE_END && pEntry->nWID < RES_CHRATR_BEGIN && pEntry->nWID > RES_TXTATR_END ) { pStates[i] = beans::PropertyState_DEFAULT_VALUE; } .... } 

मुझे तुरंत समझ में नहीं आ रहा है कि इस स्थिति की समस्या क्या है, इसलिए, एक विस्तारित कोड टुकड़ा पूर्वप्रमाणित फ़ाइल के बाहर लिखा गया था:

 if (((SW_PROPERTY_STATE_CALLER_SWX_TEXT_PORTION == eCaller) || (SW_PROPERTY_STATE_CALLER_SWX_TEXT_PORTION_TOLERANT == eCaller)) && pEntry->nWID < (20000 + 1600) && pEntry->nWID > ((20000 + 2400) + 199) && pEntry->nWID < 1 && pEntry->nWID > 63 ) { pStates[i] = beans::PropertyState_DEFAULT_VALUE; } 

ऐसा हुआ कि संख्याओं द्वारा निर्दिष्ट स्थिति में निर्दिष्ट 4 श्रेणियों में एक भी संख्या शामिल नहीं है। डेवलपर्स ने एक गलती की।

V590 '* pData <= MAXLEVEL && * pData <= 9' अभिव्यक्ति का निरीक्षण करने पर विचार करें। अभिव्यक्ति अत्यधिक है या एक गलत चित्रण है। ww8par2.cxx 756

 const sal_uInt8 MAXLEVEL = 10; void SwWW8ImplReader::Read_ANLevelNo(....) { .... // Range WW:1..9 -> SW:0..8 no bullets / numbering if (*pData <= MAXLEVEL && *pData <= 9) { .... } else if( *pData == 10 || *pData == 11 ) { // remember type, the rest happens at Sprm 12 m_xStyles->mnWwNumLevel = *pData; } .... } 

इस तथ्य के कारण कि पहली स्थिति 10 के मान के साथ एक स्थिरांक का उपयोग करती है, स्थिति बेमानी हो गई। इस प्रकार के कोड को फिर से लिखा जा सकता है:

 if (*pData <= 9) { .... } else if( *pData == 10 || *pData == 11 ) { .... } 

लेकिन शायद प्रस्तुत कोड में एक और समस्या थी।

V757 यह संभव है कि 'डायनेमिक_कास्ट' का उपयोग करके टाइप रूपांतरण के बाद एक गलत चर की तुलना नल्टर के साथ की जाती है। चेक लाइनें: 2709, 2710. menu.cxx 2709

 void PopupMenu::ClosePopup(Menu* pMenu) { MenuFloatingWindow* p = dynamic_cast<MenuFloatingWindow*>(ImplGetWindow()); PopupMenu *pPopup = dynamic_cast<PopupMenu*>(pMenu); if (p && pMenu) p->KillActivePopup(pPopup); } 

सबसे अधिक संभावना है, स्थिति में एक त्रुटि है। पॉइंटर्स p और pPopup की जांच करना आवश्यक था।

V668 नल के खिलाफ 'm_pStream' पॉइंटर के परीक्षण में कोई समझदारी नहीं है, क्योंकि 'नए' ऑपरेटर का उपयोग करके मेमोरी आवंटित की गई थी। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। zipfile.cxx 408

 ZipFile::ZipFile(const std::wstring &FileName) : m_pStream(nullptr), m_bShouldFree(true) { m_pStream = new FileStream(FileName.c_str()); if (m_pStream && !isZipStream(m_pStream)) { delete m_pStream; m_pStream = nullptr; } } 

विश्लेषक ने एक ऐसी स्थिति का पता लगाया जहां नए ऑपरेटर द्वारा दिए गए पॉइंटर का मूल्य शून्य की तुलना में है। C ++ भाषा मानक के अनुसार, यदि मेमोरी आवंटन संभव नहीं है, तो नया ऑपरेटर एक अपवाद std :: bad_alloc फेंक देगा। लिबरऑफिस परियोजना में केवल 45 ऐसे स्थान पाए गए, जो इस तरह के कोड की मात्रा के लिए बहुत कम हैं। लेकिन फिर भी, यह उपयोगकर्ताओं के लिए समस्याएं पैदा कर सकता है। डेवलपर्स को अनावश्यक जांच को हटा देना चाहिए या इस तरह से ऑब्जेक्ट बनाना चाहिए:

 m_pStream = new (std::nothrow) FileStream(FileName.c_str()); 

V728 एक अत्यधिक जाँच को सरल बनाया जा सकता है। द '(A &&! B) || (ए! और बी) अभिव्यक्ति 'बूल (ए) के बराबर है! = बूल (बी)' अभिव्यक्ति। toolbox2.cxx 1042

 void ToolBox::SetItemImageMirrorMode( sal_uInt16 nItemId, bool bMirror ) { ImplToolItems::size_type nPos = GetItemPos( nItemId ); if ( nPos != ITEM_NOTFOUND ) { ImplToolItem* pItem = &mpData->m_aItems[nPos]; if ((pItem->mbMirrorMode && !bMirror) || // <= (!pItem->mbMirrorMode && bMirror)) // <= { .... } } } 

बहुत समय पहले, V728 डायग्नॉस्टिक्स का विस्तार उन मामलों में किया गया था, जो सबसे अधिक संभावना है, गलत नहीं हैं, लेकिन कोड को जटिल करते हैं। और जटिल कोड में, अभी या बाद में त्रुटियां अभी भी बनी हुई हैं।

यह स्थिति निम्नलिखित के लिए सरल है:

 if (pItem->mbMirrorMode != bMirror) { .... } 

परियोजना में लगभग 60 समान संरचनाएं पाई जाती हैं, उनमें से कुछ बहुत, बहुत भारी हैं। परियोजना के लेखकों को पीवीएस-स्टूडियो विश्लेषक की पूरी रिपोर्ट से परिचित होना चाहिए।

सुरक्षा के मुद्दे

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। docxattributeoutput.cxx 1571

 void DocxAttributeOutput::DoWritePermissionTagEnd( const OUString & permission) { OUString permissionIdAndName; if (permission.startsWith("permission-for-group:", &permissionIdAndName)) { const sal_Int32 sparatorIndex = permissionIdAndName.indexOf(':'); const OUString permissionId = permissionIdAndName.copy(....); const OString rId = OUStringToOString(....).getStr(); m_pSerializer->singleElementNS(XML_w, XML_permEnd, FSNS(XML_w, XML_id), rId.getStr(), FSEND); } else { const sal_Int32 sparatorIndex = permissionIdAndName.indexOf(':'); const OUString permissionId = permissionIdAndName.copy(....); const OString rId = OUStringToOString(....).getStr(); m_pSerializer->singleElementNS(XML_w, XML_permEnd, FSNS(XML_w, XML_id), rId.getStr(), FSEND); } } 

एक बहुत बड़े कोड को यहां कॉपी किया जाता है। एक फ़ंक्शन के लिए जो कुछ अधिकारों को बदलता है, पहचानी गई समस्या बहुत संदिग्ध लगती है।

V1001 'DL' वैरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। cipher.cxx 811

 static void BF_updateECB( CipherContextBF *ctx, rtlCipherDirection direction, const sal_uInt8 *pData, sal_uInt8 *pBuffer, sal_Size nLength) { CipherKeyBF *key; sal_uInt32 DL, DR; key = &(ctx->m_key); if (direction == rtl_Cipher_DirectionEncode) { RTL_CIPHER_NTOHL64(pData, DL, DR, nLength); BF_encode(key, &DL, &DR); RTL_CIPHER_HTONL(DL, pBuffer); RTL_CIPHER_HTONL(DR, pBuffer); } else { RTL_CIPHER_NTOHL(pData, DL); RTL_CIPHER_NTOHL(pData, DR); BF_decode(key, &DL, &DR); RTL_CIPHER_HTONL64(DL, DR, pBuffer, nLength); } DL = DR = 0; } 

DL और DR वेरिएबल्स फ़ंक्शन के अंत में एक साधारण असाइनमेंट द्वारा nullified हैं और अब उपयोग नहीं किए जाते हैं। कंपाइलर के लिए, यह अनुकूलन के लिए कमांड हटाने का एक बहाना है।

Windows अनुप्रयोगों में चर को ठीक से साफ करने के लिए, आप इस तरह से कोड को फिर से लिख सकते हैं:

 RtlSecureZeroMemory(&DL, sizeof(DL)); RtlSecureZeroMemory(&DR, sizeof(DR)); 

लेकिन लिब्रे ऑफिस के लिए, यहां एक क्रॉस-प्लेटफॉर्म समाधान की आवश्यकता है।

एक अन्य समारोह से इसी तरह की चेतावनी:

• V1001 'DL' वैरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। cipher.cxx 860

V764 'क्वेरीस्ट्रीम' फंक्शन: 'आरयूआरआई' और 'आरपासवर्ड' में दिए गए तर्कों का संभावित गलत क्रम। tdoc_storage.cxx 271

 css::uno::Reference< css::io::XStream > queryStream( const css::uno::Reference< css::embed::XStorage > & xParentStorage, const OUString & rPassword, const OUString & rUri, StorageAccessMode eMode, bool bTruncate ); uno::Reference< io::XOutputStream > StorageElementFactory::createOutputStream( const OUString & rUri, const OUString & rPassword, bool bTruncate ) { .... uno::Reference< io::XStream > xStream = queryStream( xParentStorage, rUri, rPassword, READ_WRITE_CREATE, bTruncate ); .... } 

कृपया ध्यान दें कि क्वेरीस्ट्रीम फ़ंक्शन में, पैरामीटर सूची में, पहले rassassword और फिर rUri । कोड में एक जगह थी जहां इस फ़ंक्शन को कॉल करने पर संबंधित तर्कों को मिलाया गया था।

V794 असाइनमेंट ऑपरेटर को 'यह == & rToBeCopied' के मामले से सुरक्षित किया जाना चाहिए। hommatrixtemplate.hxx 121

 ImplHomMatrixTemplate& operator=(....) { // complete initialization using copy for(sal_uInt16 a(0); a < (RowSize - 1); a++) { memcpy(&maLine[a], &rToBeCopied.maLine[a], sizeof(....)); } if(rToBeCopied.mpLine) { mpLine.reset( new ImplMatLine< RowSize >(....) ); } return *this; } 

यह मामला सुरक्षित कोड लेखन के बारे में अधिक है। किसी वस्तु को स्वयं निर्दिष्ट करने के लिए कॉपी स्टेटमेंट की कोई जांच नहीं है। कुल में, परियोजना में कॉपी ऑपरेटर के लगभग 30 कार्यान्वयन हैं।

SysAllocString के साथ त्रुटियां

V649 समान सशर्त अभिव्यक्तियों के साथ दो 'यदि' कथन हैं। पहले 'if' स्टेटमेंट में फंक्शन रिटर्न होता है। इसका मतलब यह है कि दूसरा 'अगर' कथन संवेदनहीन है। चेक लाइनें: 125, 137. acctable.cxx 137

 STDMETHODIMP CAccTable::get_columnDescription(long column, BSTR * description) { SolarMutexGuard g; ENTER_PROTECTED_BLOCK // #CHECK# if(description == nullptr) return E_INVALIDARG; // #CHECK XInterface# if(!pRXTable.is()) return E_FAIL; .... SAFE_SYSFREESTRING(*description); *description = SysAllocString(o3tl::toW(ouStr.getStr())); if(description==nullptr) // <= return E_FAIL; return S_OK; LEAVE_PROTECTED_BLOCK } 

SysAllocString () फ़ंक्शन एक पॉइंटर देता है जो NULL हो सकता है । इस कोड के लेखक द्वारा कुछ अजीब लिखा गया था। मेमोरी को आवंटित करने के लिए सूचक की जांच नहीं की जाती है, जिससे कार्यक्रम में समस्याएं हो सकती हैं।

अन्य कार्यों से इसी तरह की चेतावनी:

• V649 समान सशर्त अभिव्यक्तियों के साथ दो 'यदि' कथन हैं। पहले 'if' स्टेटमेंट में फंक्शन रिटर्न होता है। इसका मतलब यह है कि दूसरा 'अगर' कथन संवेदनहीन है। चेक लाइनें: 344, 356. acctable.cxx 356
• V649 समान सशर्त अभिव्यक्तियों के साथ दो 'यदि' कथन हैं। पहले 'if' स्टेटमेंट में फंक्शन रिटर्न होता है। इसका मतलब यह है कि दूसरा 'अगर' कथन संवेदनहीन है। चेक लाइनें: 213, 219. trvlfrm.cxx 219

V530 'SysAllocString' फ़ंक्शन के रिटर्न मान का उपयोग करने की आवश्यकता है। maccessible.cxx 1077

 STDMETHODIMP CMAccessible::put_accValue(....) { .... if(varChild.lVal==CHILDID_SELF) { SysAllocString(m_pszValue); m_pszValue=SysAllocString(szValue); return S_OK; } .... } 

SysAllocString () फ़ंक्शन के लिए एक कॉल के परिणाम का उपयोग नहीं किया जाता है। डेवलपर्स को कोड के इस टुकड़े पर ध्यान देना चाहिए।

अनेक वस्तुओं का संग्रह

रिटर्न स्टेटमेंट में V716 संदिग्ध प्रकार का रूपांतरण: वापस HRESULT, लेकिन फ़ंक्शन वास्तव में BOOL लौटाता है। maccessible.cxx 2649

 BOOL CMAccessible::get_IAccessibleFromXAccessible(....) { ENTER_PROTECTED_BLOCK // #CHECK# if(ppIA == nullptr) { return E_INVALIDARG; // <= } BOOL isGet = FALSE; if(g_pAgent) isGet = g_pAgent->GetIAccessibleFromXAccessible(....); if(isGet) return TRUE; else return FALSE; LEAVE_PROTECTED_BLOCK } 

फ़ंक्शन के निष्पादन की शाखाओं में से एक एक मान देता है जिसका प्रकार फ़ंक्शन के रिटर्न मूल्य के प्रकार से मेल नहीं खाता है।HRESULT प्रकार का BOOL प्रकार की तुलना में अधिक जटिल प्रारूप है और इसे संचालन स्थितियों को संग्रहीत करने के लिए डिज़ाइन किया गया है। उदाहरण के लिए, E_INVALIDARG का मान 0x80070057L है । उदाहरण के लिए, यह लिखना सही होगा:

 return FAILED(E_INVALIDARG); 

आप इसके बारे में V716 डायग्नोस्टिक डॉक्यूमेंटेशन में अधिक पढ़ सकते हैं।

कुछ और समान स्थान:

• रिटर्न स्टेटमेंट में V716 संदिग्ध प्रकार का रूपांतरण: वापस HRESULT, लेकिन फ़ंक्शन वास्तव में BOOL लौटाता है। inprocembobj.cxx 1299
• रिटर्न स्टेटमेंट में V716 संदिग्ध प्रकार का रूपांतरण: वापस HRESULT, लेकिन फ़ंक्शन वास्तव में BOOL लौटाता है। maccessible.cxx 2660

V670 ized m_aModifyListeners 'के सदस्य को शुरू करने के लिए अनइंस्टाल्यूटेड क्लास सदस्य' m_aMutex 'का उपयोग किया जाता है। याद रखें कि सदस्यों को एक वर्ग के अंदर उनकी घोषणाओं के क्रम में आरंभीकृत किया जाता है। fmgridif.cxx 1033

 FmXGridPeer::FmXGridPeer(const Reference< XComponentContext >& _rxContext) :m_aModifyListeners(m_aMutex) ,m_aUpdateListeners(m_aMutex) ,m_aContainerListeners(m_aMutex) ,m_aSelectionListeners(m_aMutex) ,m_aGridControlListeners(m_aMutex) ,m_aMode( getDataModeIdentifier() ) ,m_nCursorListening(0) ,m_bInterceptingDispatch(false) ,m_xContext(_rxContext) { // Create must be called after this constructor m_pGridListener.reset( new GridListenerDelegator( this ) ); } class __declspec(dllexport) FmXGridPeer: public cppu::ImplInheritanceHelper<....> { .... ::comphelper::OInterfaceContainerHelper2 m_aModifyListeners, m_aUpdateListeners, m_aContainerListeners, m_aSelectionListeners, m_aGridControlListeners; .... protected: css::uno::Reference< css::uno::XComponentContext > m_xContext; ::osl::Mutex m_aMutex; .... }; 

भाषा मानक के अनुसार, कंस्ट्रक्टर में वर्ग के सदस्यों के आरंभ का क्रम वर्ग में उनकी घोषणा के क्रम में होता है। हमारे मामले में, m_autex क्षेत्र को कक्षा के पांच अन्य क्षेत्रों के आरंभ में भाग लेने के बाद आरम्भ किया जाएगा।

यहाँ क्लास के खेतों में से एक का निर्माण कैसा दिखता है:

 OInterfaceContainerHelper2( ::osl::Mutex & rMutex ); 

म्यूटेक्स ऑब्जेक्ट को संदर्भ द्वारा पारित किया जाता है। इस मामले में, विभिन्न समस्याएं उत्पन्न हो सकती हैं: वस्तु के परिवर्तन के बाद के नुकसान के लिए असमान स्मृति तक पहुँचने से।

V763 'nNativeNumberMode' पैरामीटर हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। Calendar_jewish.cxx 286

 OUString SAL_CALL Calendar_jewish::getDisplayString(...., sal_Int16 nNativeNumberMode ) { // make Hebrew number for Jewish calendar nNativeNumberMode = NativeNumberMode::NATNUM2; if (nCalendarDisplayCode == CalendarDisplayCode::SHORT_YEAR) { sal_Int32 value = getValue(CalendarFieldIndex::YEAR) % 1000; return mxNatNum->getNativeNumberString(...., nNativeNumberMode ); } else return Calendar_gregorian::getDisplayString(...., nNativeNumberMode ); } 

विभिन्न कारणों से फ़ंक्शन तर्क ओवरराइट किए जाते हैं: कंपाइलर चेतावनियां, पिछड़ी संगतता, बैसाखी, आदि। हालाँकि, इनमें से कोई भी समाधान अच्छा नहीं है, और कोड भ्रामक लगता है।

आपको इस स्थान के कोड की समीक्षा करनी चाहिए और कुछ इसी तरह की:

• V763 पैरामीटर 'bExtendedInfo' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। ग्राफिकफिल्टर 2। XXX 442
• V763 पैरामीटर 'nVerbID' हमेशा उपयोग किए जाने से पहले फ़ंक्शन बॉडी में फिर से लिखा जाता है। oleembed.cxx 841
• V763 Parameter 'pCursor' is always rewritten in function body before being used. edlingu.cxx 843
• V763 Parameter 'pOutput' is always rewritten in function body before being used. vnew.cxx 181
• V763 Parameter 'pOutput' is always rewritten in function body before being used. vnew.cxx 256

निष्कर्ष

लिबरऑफिस कोड की जांच करने की इच्छा उत्पाद के मेरे व्यक्तिगत उपयोग के बाद दिखाई दी। किसी कारण से, कुछ यादृच्छिक लॉन्च के साथ, पाठ बिल्कुल सभी मेनू आइटम से गायब हो जाता है। केवल चिह्न और नीरस धारियाँ रहती हैं। त्रुटि संभवतः उच्च-स्तरीय है और संभवतः, इसे स्थैतिक विश्लेषण टूल की सहायता से नहीं पाया जा सकता है। फिर भी, विश्लेषक ने बहुत सारी समस्याएं पाई हैं जो इस से संबंधित नहीं हैं, और मुझे खुशी होगी अगर लिब्रे ऑफिस डेवलपर्स स्थिर कोड विश्लेषक पर ध्यान दें और परियोजना की गुणवत्ता और विश्वसनीयता में सुधार करने के लिए उनका उपयोग करने का प्रयास करें। यह सभी के लिए उपयोगी होगा।

आपका ध्यान के लिए धन्यवाद। हमारे चैनलों की सदस्यता लें और प्रोग्रामिंग की दुनिया से खबरों के लिए बने रहें!

• Vk: @pvsstudio_rus
• टेलीग्राम: @pvsstudio_rus
• इंस्टाग्राम: @pvsstudio_rus
• ट्विटर: @pvsstudio_rus
• YouTube: @PVSStudioTool

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: Svyatoslav Razmyslov। लिबरऑफिस: एकाउंटेंट का दुःस्वप्न