हुआवेई क्लाउड: पीवीएस-स्टूडियो टुडे में यह बादल छाए रहेंगे

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

परिचय

यदि आप PVS-Studio टीम पोस्ट का अनुसरण कर रहे हैं, तो आपने शायद देखा है कि हम क्लाउड टेक्नोलॉजी में हाल ही में गहरी खुदाई कर रहे हैं। हमने पहले ही इस विषय को कवर करते हुए कई लेख प्रकाशित किए हैं:

• पीवीएस-स्टूडियो इन द क्लाउड्स: एज़्योर देवओपीएस
• पीवीएस-स्टूडियो इन द क्लाउड्स: ट्रैविस सीआई
• पीवीएस-स्टूडियो इन द क्लाउड्स: सर्कलसीआई
• पीवीएस-स्टूडियो इन द क्लाउड्स: गिटलैब सीआई / सीडी

जब मैं आगामी लेख के लिए एक असामान्य परियोजना की तलाश कर रहा था, मुझे हुआवेई की नौकरी की पेशकश के साथ एक ईमेल मिला। इस कंपनी के बारे में कुछ जानकारी एकत्र करने के बाद, यह पता चला कि उनकी अपनी क्लाउड सेवाएं थीं, लेकिन मुख्य बात यह है कि इन सेवाओं का स्रोत कोड GitHub पर उपलब्ध है। यह इस लेख के लिए इस कंपनी को चुनने का मुख्य कारण था। जैसा कि एक चीनी ऋषि ने कहा: "दुर्घटनाएं आकस्मिक नहीं हैं।"

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

• पीवीएस-स्टूडियो विश्लेषण का एकीकरण सोनारक्यूब में हुआ
• जेनकींस में चल रहा पीवीएस-स्टूडियो

परियोजना विश्लेषण

जब मैं लेख के लिए कुछ शोध कर रहा था, तो मुझे पता चला कि Huawei के पास उपलब्ध जानकारी, मैनुअल और उनकी क्लाउड सेवाओं के स्रोतों के साथ एक डेवलपर केंद्र था। इन सेवाओं को बनाने के लिए विभिन्न प्रकार की प्रोग्रामिंग भाषाओं का उपयोग किया गया था, लेकिन गो, जावा और पायथन जैसी भाषाएँ सबसे अधिक प्रचलित थीं।

चूंकि मैं जावा में विशेषज्ञ हूं, इसलिए परियोजनाओं को मेरे ज्ञान और कौशल को ध्यान में रखते हुए चुना गया है। आप एक GitHub रिपॉजिटरी huaweicloud में लेख में प्रोजेक्ट स्रोतों का विश्लेषण कर सकते हैं।

परियोजनाओं का विश्लेषण करने के लिए, मुझे केवल कुछ चीजों की आवश्यकता थी:

• भंडार से परियोजनाएं प्राप्त करें;
• स्टार्ट-अप जावा विश्लेषक निर्देशों का उपयोग करें और प्रत्येक प्रोजेक्ट पर विश्लेषण चलाएं।

परियोजनाओं का विश्लेषण करने के बाद, हमने उनमें से केवल तीन का चयन किया, जिस पर हम ध्यान देना चाहेंगे। यह इस तथ्य के कारण है कि बाकी जावा परियोजनाओं का आकार बहुत छोटा निकला।

परियोजना विश्लेषण परिणाम (चेतावनियों की संख्या और फाइलों की संख्या):

• हुवाइक्लाउड-एसडीके-जावा : 31 - उच्च, 2 - मध्यम और 16 - निम्न, 2700+ फाइलें।
• हुवाइक्लाउड-डिस-एजेंट : 7 - हाई, 6 - मीडियम और 6 - लो, 100+ फाइल्स।
• हुवाइक्लाउड-एसडीके-जावा-डिस : 15 - हाई, 6 - मीडियम और 16 - लो, 270+ फाइल्स।

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

परियोजना के विश्लेषण के रूप में मैंने केवल सबसे हॉटशॉट चेतावनियों को चुना, जिसके बारे में मैं इस लेख में बात करूंगा।

आरंभीकरण क्रम

V6050 वर्ग आरंभीकरण चक्र मौजूद है। 'लॉग' के आरंभीकरण से पहले 'INSTANCE' का प्रारंभ दिखाई देता है। अनट्रस्टेडएसएसएल.जावा (32), अनट्रस्टेडएसएसएल.जावा (59), अनट्रिस्वर्डएसएसएल.जावा (33)

public class UntrustedSSL { private static final UntrustedSSL INSTANCE = new UntrustedSSL(); private static final Logger LOG = LoggerFactory.getLogger(UntrustedSSL.class); .... private UntrustedSSL() { try { .... } catch (Throwable t) { LOG.error(t.getMessage(), t); // <= } } } 

अगर UnrustedSSL क्लास कंस्ट्रक्टर में कोई अपवाद है, तो लॉग लॉगर का उपयोग करके इस अपवाद के बारे में जानकारी कैच ब्लॉक में लॉग होती है । हालाँकि, स्थिर फ़ील्ड्स के आरंभीकरण क्रम के कारण, INSTANCE फ़ील्ड को आरम्भ करने के क्षण में, LOG अभी तक आरंभीकृत नहीं हुआ है। इसलिए, यदि आप कंस्ट्रक्टर में अपवाद के बारे में जानकारी लॉग करते हैं, तो इसका परिणाम NullPointerException में होगा। यह अपवाद एक अन्य अपवाद ExceptionInInitializerError का कारण है, जो कि तब होता है जब स्थैतिक क्षेत्र को आरंभिक रूप से अपवादित किया गया था। इस समस्या को हल करने के लिए आपको लॉग इनिशियलाइज़ेशन को INSTANCE इनिशियलाइज़ेशन से पहले रखना होगा ।

असंगत टाइपो

V6005 चर 'this.metricSchema' खुद को सौंपा गया है। OpenTSDBSchema.java (72)

 public class OpenTSDBSchema { @JsonProperty("metric") private List<SchemaField> metricSchema; .... public void setMetricsSchema(List<SchemaField> metricsSchema) { this.metricSchema = metricSchema; // <= } public void setMetricSchema(List<SchemaField> metricSchema) { this.metricSchema = metricSchema; } .... } 

दोनों विधियाँ मीट्रिकस्चेमा फ़ील्ड सेट करती हैं, लेकिन विधि के नाम एक 's' चिन्ह से भिन्न होते हैं। प्रोग्रामर ने विधि के नाम के अनुसार इन विधियों के तर्कों का नाम दिया। परिणामस्वरूप, विश्लेषक जिस लाइन की ओर इशारा करता है , वह मीट्रिक फ़ील्ड अपने आप में सम्‍मिलित हो जाता है, और मैट्रिक्ससचेमा विधि का तर्क उपयोग नहीं किया जाता है।

V6005 चर 'सस्पेंड' खुद को सौंपा गया है। SuspendTransferTaskRequest.java (77)

 public class SuspendTransferTaskRequest { .... private boolean suspend; .... public void setSuspend(boolean suspend) { suspend = suspend; } .... } 

यहां लापरवाही से संबंधित एक तुच्छ त्रुटि है, जिसके कारण निलंबित तर्क को खुद को सौंपा गया है। परिणामस्वरूप, निलंबित फ़ील्ड को प्राप्त तर्क के मान को निहित नहीं किया जाएगा। सही संस्करण:

 public void setSuspend(boolean suspend) { this.suspend = suspend; } 

स्थितियां पूर्वनिर्धारण

जैसा कि अक्सर होता है, V6007 नियम चेतावनी मात्रा के मामले में आगे टूट जाता है।

V6007 अभिव्यक्ति 'फ़ायरवॉलपॉलिशियड == नल' हमेशा गलत होता है। फ़ायरवॉलपॉलीस्कूल सेवाइम्प्ल.जावा (125)

 public FirewallPolicy removeFirewallRuleFromPolicy(String firewallPolicyId, String firewallRuleId) { checkNotNull(firewallPolicyId); checkNotNull(firewallRuleId); checkState(!(firewallPolicyId == null && firewallRuleId == null), "Either a Firewall Policy or Firewall Rule identifier must be set"); .... } 

इस विधि में तर्कों की जाँच nNotNull विधि द्वारा की जाती है:

 @CanIgnoreReturnValue public static <T> T checkNotNull(T reference) { if (reference == null) { throw new NullPointerException(); } else { return reference; } } 

CheckNotNull विधि द्वारा तर्क की जाँच करने के बाद, आप 100% सुनिश्चित हो सकते हैं कि इस पद्धति को दिया गया तर्क शून्य के बराबर नहीं है। चूंकि CheckNotNull विधि द्वारा removeFirewallRuleFromPolicy विधि के दोनों तर्कों की जाँच की जाती है, इसलिए नल के लिए उनकी आगे की जांच का कोई मतलब नहीं है। हालाँकि, अभिव्यक्ति, जहाँ फ़ायरवॉलपॉलीसाइड और फ़ायरवॉलरुल्ड तर्क शून्य के लिए फिर से जाँच किए जाते हैं, चेकस्टैट विधि के पहले तर्क के रूप में पारित किया जाता है।

फायरवॉल के लिए इसी तरह की चेतावनी जारी की जाती है।

• V6007 अभिव्यक्ति 'फ़ायरवॉलRuleId == नल' हमेशा गलत है। फ़ायरवॉलपॉलीस्कूल सेवाइम्प्ल.जावा (125)

V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। NetworkPolicyServiceImpl.java (60)

 private Invocation<NetworkServicePolicies> buildInvocation(Map<String, String> filteringParams) { .... if (filteringParams == null) { return servicePoliciesInvocation; } if (filteringParams != null) { // <= .... } return servicePoliciesInvocation; } 

इस विधि में, फ़िल्टरिंगपार्म्स तर्क शून्य है , तो विधि एक मान लौटाती है। यही कारण है कि विश्लेषक जो चेक इंगित करता है वह हमेशा सही होगा जो बदले में, इसका मतलब है कि यह चेक अर्थहीन है।

13 और कक्षाएं समान हैं:

• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। PolicyRuleServiceImpl.java (58)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। GroupServiceImpl.java (58)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। एक्सटर्नलशिप सेवाइम्प्ल.जावा (57)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। L3policyServiceImpl.java (57)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। PolicyRuleSetServiceImpl.java (58)
• और इसी तरह ...

अशक्त संदर्भ

V6008 'm.blockDeviceMapping' के संभावित अशक्त। नोवासेवरक्रिएट.जावा (390)

 @Override public ServerCreateBuilder blockDevice(BlockDeviceMappingCreate blockDevice) { if (blockDevice != null && m.blockDeviceMapping == null) { m.blockDeviceMapping = Lists.newArrayList(); } m.blockDeviceMapping.add(blockDevice); // <= return this; } 

इस विधि में, block.evice तर्क के अशक्त होने पर m.blockDeviceMapping संदर्भ फ़ील्ड का आरंभीकरण नहीं होगा। इस फ़ील्ड को केवल इस विधि में आरंभीकृत किया गया है, इसलिए m.blockDeviceMapping फ़ील्ड से ऐड मेथड को कॉल करने पर, NullPointerException होगा।

V6008 फ़ंक्शन '<init>' में 'FileId.get (पथ)' की संभावित अशक्तता । TrackedFile.java (140), TrackedFile.java (115)

 public TrackedFile(FileFlow<?> flow, Path path) throws IOException { this(flow, path, FileId.get(path), ....); } 

TrackedFile वर्ग के निर्माता को तीसरे तर्क के रूप में स्थिर FileId.get (पथ) विधि का परिणाम प्राप्त होता है। लेकिन यह विधि शून्य हो सकती है :

 public static FileId get(Path file) throws IOException { if (!Files.exists(file)) { return null; } .... } 

इसके द्वारा उपयोग किए जाने वाले निर्माता में, आईडी तर्क तब तक नहीं बदलता है जब तक कि इसका पहला उपयोग न हो जाए:

 public TrackedFile(...., ...., FileId id, ....) throws IOException { .... FileId newId = FileId.get(path); if (!id.equals(newId)) { .... } } 

जैसा कि हम देख सकते हैं, अगर शून्य को विधि के तीसरे तर्क के रूप में पारित किया जाता है, तो एक अपवाद होगा।

यहाँ एक और समान मामला है:

• V6008 'बफर' की संभावित अशक्तता। PublishingQueue.java (518)

V6008 'डेटाटेम्पाइल' के संभावित अशक्तता। कैचेमनगर.जावा (91)

 @Override public void putToCache(PutRecordsRequest putRecordsRequest) { .... if (dataTmpFile == null || !dataTmpFile.exists()) { try { dataTmpFile.createNewFile(); // <= } catch (IOException e) { LOGGER.error("Failed to create cache tmp file, return.", e); return ; } } .... } 

फिर से एन.पी.ई. सशर्त ऑपरेटर में कई चेक शून्य वस्तु डेटाटैम्पफाइल को आगे की परिधि के लिए अनुमति देते हैं। मुझे लगता है कि यहां दो टाइपो हैं और चेक वास्तव में इस तरह दिखना चाहिए:

 if (dataTmpFile != null && !dataTmpFile.exists()) 

सबस्ट्रिंग और नकारात्मक संख्या

V6009 ' प्रतिस्थापन ' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। तर्क का निरीक्षण करें: 2. RemoveVersionProjectIdFromURL.java (37)

 @Override public String apply(String url) { String urlRmovePojectId = url.substring(0, url.lastIndexOf("/")); return urlRmovePojectId.substring(0, urlRmovePojectId.lastIndexOf("/")); } 

निहितार्थ यह है कि इस पद्धति को एक स्ट्रिंग के रूप में एक URL मिलता है, जो किसी भी तरह से मान्य नहीं है। बाद में, इस स्ट्रिंग को lastIndexOf विधि का उपयोग करके कई बार काट दिया जाता है। यदि विधि lastIndexOf को स्ट्रिंग में मेल नहीं मिलती है, तो यह -1 वापस आ जाएगी। यह StringIndexOutOfBoundsException को ले जाएगा, क्योंकि सबस्ट्रिंग विधि के तर्कों को गैर-नकारात्मक संख्या में होना चाहिए। सही विधि के संचालन के लिए, किसी को इनपुट तर्क सत्यापन को जोड़ना होगा या जांचना होगा कि lastIndexOf विधि के परिणाम गैर-नकारात्मक संख्याएं हैं।

यहाँ कुछ अन्य स्निपेट इसी तरह की चीजें हैं:

• V6009 'प्रतिस्थापन' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। निरीक्षण तर्क: 2. RemoveProjectIdFromURL.java (37)
• V6009 'प्रतिस्थापन' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। तर्क का निरीक्षण करें: 2. RemoveVersionProjectIdFromURL.java (38)

भूल गए परिणाम

V6010 फ़ंक्शन ' कॉनकैट ' के रिटर्न मान का उपयोग करने की आवश्यकता है। AKSK.java (278)

 public static String buildCanonicalHost(URL url) { String host = url.getHost(); int port = url.getPort(); if (port > -1) { host.concat(":" + Integer.toString(port)); } return host; } 

इस कोड को लिखते समय, इसके लेखक ने इस बात को ध्यान में नहीं रखा कि कॉन्ट्रास्ट विधि की एक कॉल स्ट्रिंग प्रकार की वस्तुओं की अपरिहार्यता के कारण होस्ट स्ट्रिंग को नहीं बदलेगी। सही विधि के संचालन के लिए, कॉनकैट विधि का परिणाम होस्ट ब्लॉक में अगर ब्लॉक में सौंपा जाना है। सही संस्करण:

 if (port > -1) { host = host.concat(":" + Integer.toString(port)); } 

अप्रयुक्त चर

V6021 चर 'url' का उपयोग नहीं किया गया है। TriggerV2Service.java (95)

 public ActionResponse deleteAllTriggersForFunction(String functionUrn) { checkArgument(!Strings.isNullOrEmpty(functionUrn), ....); String url = ClientConstants.FGS_TRIGGERS_V2 + ClientConstants.URI_SEP + functionUrn; return deleteWithResponse(uri(triggersUrlFmt, functionUrn)).execute(); } 

इस विधि में, url वैरिएबल को इसके आरंभीकरण के बाद उपयोग नहीं किया जाता है। सबसे अधिक संभावना है, url चर को functionUrn के बजाय दूसरे तर्क के रूप में uri विधि में पास किया जाना चाहिए, क्योंकि functionUrn चर url चर के आरंभ में भाग लेता है।

तर्क ने निर्माणकर्ता का उपयोग नहीं किया

V6022 पैरामीटर 'returnType' का उपयोग कंस्ट्रक्टर बॉडी के अंदर नहीं किया जाता है। HttpRequest.java (68)

 public class HttpReQuest<R> { .... Class<R> returnType; .... public HttpRequest(...., Class<R> returnType) // <= { this.endpoint = endpoint; this.path = path; this.method = method; this.entity = entity; } .... public Class<R> getReturnType() { return returnType; } .... } 

इस निर्माता में, प्रोग्रामर रिटर्न टाइप तर्क का उपयोग करना भूल गया, और रिटर्न टाइप फ़ील्ड में इसके मूल्य को असाइन करता है। इसीलिए, जब इस रचनाकार द्वारा बनाई गई ऑब्जेक्ट से getReturnType विधि को कॉल करते हैं, तो डिफ़ॉल्ट रूप से नल वापस आ जाएगा। लेकिन सबसे अधिक संभावना है, प्रोग्रामर को ऑब्जेक्ट प्राप्त करने का इरादा था, पहले कंस्ट्रक्टर को पास किया गया था।

एक ही कार्यक्षमता

V6032 यह अजीब है कि विधि 'सक्षम' का शरीर पूरी तरह से किसी अन्य विधि 'अक्षम' के शरीर के बराबर है। ServiceAction.java (32), ServiceAction.java (36)

 public class ServiceAction implements ModelEntity { private String binary; private String host; private ServiceAction(String binary, String host) { this.binary = binary; this.host = host; } public static ServiceAction enable(String binary, String host) { // <= return new ServiceAction(binary, host); } public static ServiceAction disable(String binary, String host) { // <= return new ServiceAction(binary, host); } .... } 

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

मुख्य बात की जांच करना भूल गए

V6060 नल के खिलाफ सत्यापित होने से पहले ' परम ' संदर्भ का उपयोग किया गया था। DomainService.java (49), DomainService.java (46)

 public Domains list(Map<String, String> params) { Preconditions.checkNotNull(params.get("page_size"), ....); Preconditions.checkNotNull(params.get("page_number"), ....); Invocation<Domains> domainInvocation = get(Domains.class, uri("/domains")); if (params != null) { // <= .... } return domainInvocation.execute(this.buildExecutionOptions(Domains.class)); } 

इस पद्धति में, लेखक ने नल के लिए मानचित्र प्रकार की संरचना की सामग्री की जांच करने का निर्णय लिया। ऐसा करने के लिए, परम विधि तर्क से दो बार विधि प्राप्त की जाती है। प्राप्त विधि का परिणाम CheckNotNull विधि से पारित किया गया है। सब कुछ तार्किक लगता है, लेकिन ऐसा नहीं है! अगर में अशक्त के लिए परमेस तर्क की जाँच की जाती है। इसके बाद यह उम्मीद की जाती है कि इनपुट तर्क शून्य हो सकता है, लेकिन इस जाँच से पहले, गेट विधि को पहले ही दो बार पाराम कहा जा चुका है । यदि नल को इस पद्धति के तर्क के रूप में पारित किया जाता है, तो पहली बार जब आप प्राप्त विधि को कॉल करते हैं , तो एक अपवाद फेंक दिया जाएगा।

इसी तरह की स्थिति तीन अन्य स्थानों पर होती है:

• V6060 नल के खिलाफ सत्यापित होने से पहले 'परम' संदर्भ का उपयोग किया गया था। DomainService.java (389), DomainService.java (387)
• V6060 नल के खिलाफ सत्यापित होने से पहले 'परम' संदर्भ का उपयोग किया गया था। DomainService.java (372), DomainService.java (369)
• V6060 नल के खिलाफ सत्यापित होने से पहले 'परम' संदर्भ का उपयोग किया गया था। DomainService.java (353), DomainService.java (350)

निष्कर्ष

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

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