HPCC-25955 implemented static pvs

common/workunit/workunit.cpp

@@ -8500,7 +8500,9 @@ void CLocalWorkUnit::copyWorkUnit(IConstWorkUnit *cached, bool copyStats, bool a
 bool CLocalWorkUnit::hasDebugValue(const char *propname) const
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     return p->hasProp(prop.append(lower));
@@ -8509,7 +8511,9 @@ bool CLocalWorkUnit::hasDebugValue(const char *propname) const
 IStringVal& CLocalWorkUnit::getDebugValue(const char *propname, IStringVal &str) const
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     str.set(p->queryProp(prop.append(lower).str()));
@@ -8528,7 +8532,9 @@ IStringIterator& CLocalWorkUnit::getDebugValues(const char *prop) const
     if (prop)
     {
         StringBuffer lower;
-        lower.append(prop).toLowerCase();
+        lower.append(prop);
+        if (!strchr(lower, ':'))
+            lower.toLowerCase();
         path.append(lower);
     }
     else
@@ -8539,7 +8545,9 @@ IStringIterator& CLocalWorkUnit::getDebugValues(const char *prop) const
 int CLocalWorkUnit::getDebugValueInt(const char *propname, int defVal) const
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     prop.append(lower);
@@ -8549,7 +8557,9 @@ int CLocalWorkUnit::getDebugValueInt(const char *propname, int defVal) const
 __int64 CLocalWorkUnit::getDebugValueInt64(const char *propname, __int64 defVal) const
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     prop.append(lower);
@@ -8559,7 +8569,9 @@ __int64 CLocalWorkUnit::getDebugValueInt64(const char *propname, __int64 defVal)
 double CLocalWorkUnit::getDebugValueReal(const char *propname, double defVal) const
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     prop.append(lower);
@@ -8569,7 +8581,9 @@ double CLocalWorkUnit::getDebugValueReal(const char *propname, double defVal) co
 bool CLocalWorkUnit::getDebugValueBool(const char * propname, bool defVal) const
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     prop.append(lower);
@@ -8642,7 +8656,9 @@ void CLocalWorkUnit::addProcess(const char *type, const char *instance, unsigned
 void CLocalWorkUnit::setDebugValue(const char *propname, const char *value, bool overwrite)
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     prop.append(lower);
@@ -8657,7 +8673,9 @@ void CLocalWorkUnit::setDebugValue(const char *propname, const char *value, bool
 void CLocalWorkUnit::setDebugValueInt(const char *propname, int value, bool overwrite)
 {
     StringBuffer lower;
-    lower.append(propname).toLowerCase();
+    lower.append(propname);
+    if (!strchr(lower, ':'))
+        lower.toLowerCase();
     CriticalBlock block(crit);
     StringBuffer prop("Debug/");
     prop.append(lower);

configuration/configmgr/configmgrlib/EnvironmentNode.cpp

@@ -30,18 +30,17 @@ void EnvironmentNode::addChild(std::shared_ptr<EnvironmentNode> pNode)
 
 bool EnvironmentNode::removeChild(const std::shared_ptr<EnvironmentNode> pNode, std::vector<std::string> &removedNodeIds)
 {
-    bool removed = false;
-    for (auto it=m_children.begin(); it!= m_children.end() && !removed; ++it)
+    for (auto it=m_children.begin(); it!= m_children.end(); ++it)
     {
         if (pNode == it->second)
         {
             pNode->removeAllChildren(removedNodeIds);
             removedNodeIds.emplace_back(pNode->getId());
             m_children.erase(it);
-            removed = true;
+            return true;
         }
     }
-    return removed;
+    return false;
 }
 
 

devdoc/.vitepress/config.js

@@ -3,7 +3,8 @@ export default {
     description: 'The HPCC-Platform from hpccsystems is an open source system for big data analysis. It uses a single language, platform and architecture to process data efficiently and fast.',
     base: '/HPCC-Platform/',
     srcDir: '..',
-    srcExclude: ["build/**", "dockerfiles/**", "docs/**", "esp/**", "helm/**", "initfiles/**", "plugins/**", "vcpkg/**" ],
+    srcExclude: ["build/**", "dockerfiles/**", "docs/**", "esp/**", "helm/**", "initfiles/**", "plugins/**", "vcpkg/**"],
+    ignoreDeadLinks: true,
 
     themeConfig: {
         repo: "hpcc-systems/HPCC-Platform",

devdoc/CodeSubmissions.md

@@ -37,40 +37,7 @@ Contributors should use the github reviewers section on the PR to request review
 
 Reviewers should check for PRs that are ready for their review via github's webpage (filter "review-requested:\<reviewer-id>") or via the github CLI (e.g. gh pr status).  Contributors should similarly ensure they stay up to date with any comments on requests for change on their submissions.
 
-## Target Version
+## Target branch
+The [Version support](VersionSupport.md) document contains details of the different versions that are supported, and which version should be targetted for different kinds of changes.  Occasionally earlier branches will be chosen, (e.g. security fixes to even older versions) but they should always be carefully discussed (and documented).
 
-We normally maintain 4 versions of the system - which means that each new major or minor release will typically be supported for a year.  Once a new major or minor version goes gold it becomes the current version, and should not have any changes that change the behavior of queries.  PRs should target the oldest appropriate branch, and once they are merged they will be automatically up-merged into later versions.  Which branch should changes target?  The following gives some examples and illustrates the version numbers assuming 8.12.x is the latest version.
-
-master:
-- New features.
-- Bug fixes that will change the semantics of existing queries or processes.
-- Refactoring.
-- Performance improvements (unless simple and safe)
-
-current(8.12.x):
-- Bug fixes that only change behavior where it previously crashes or had undefined behavior (If well defined but wrong need to have very strong justification to change.)
-- Fixes for race conditions (the behavior was previously indeterminate so less of an argument against it changing)
-- Data corruption fixes - on a case by case basis if they change existing query results.
-- Missing functionality that prevents features from working.
-- Changes for tech-preview work that only effect those who are using it.
-- Regressions.
-- Improvements to logging and error messages (possibly in "previous" if simple and added to help diagnose problems).
-- Occasional simple refactoring that makes up-merging simpler..
-- Changes to improve backward compatibility of new features. (E.g. adding an ignored syntax to the compiler.)
-- Performance improvements - if simple and safe
-
-previous(8.10.x):
-- Simple bug fixes that do not change behavior
-- Simple changes for missing functionality
-- Regressions with simple fixes (but care is needed if it caused a change in behavior)
-- Serious regressions
-- Complex security fixes
-
-security(8.8.x)
-- Simple security fixes
-- Complex security fixes if sufficiently serious
-
-deprecated(8.6.x)
-- Serious security fixes
-
-Occasionally earlier branches will be chosen, (e.g. security fixes to even older versions) but they should always be carefully discussed (and documented).
+Changes will always be upmerged into the next point release for all the more recent major and minor versions (and master).

devdoc/VersionSupport.md

@@ -0,0 +1,79 @@
+# Current versions
+
+| name     | version |
+| -------- | ------- |
+| early    |  9.2.0  |
+| current  |  9.0.x  |
+| previous |  8.12.x |
+| critical |  8.10.x |
+| security |  8.8.x  |
+
+## Supported versions
+
+We release a new version of the platform every 3 months.  If there are major changes in functionality, or significant backward compatibility issues then it will be tagged as a new major version, otherwise a new minor version.  We normally maintain 4 versions of the system, which means that each new release will typically be supported for a year.  Once a new major or minor version has been tagged gold it should not have any changes that change the behavior of queries.
+
+Which versions should changes be applied to?  The following gives some examples of the types of changes and which version they would be most relevant to target.
+
+"master":
+- New features.
+- Bug fixes that will change the semantics of existing queries or processes.
+- Refactoring.
+- Performance improvements (unless simple and safe)
+
+"current":
+- Bug fixes that only change behavior where it previously crashes or had undefined behavior (If well defined but wrong need to have very strong justification to change.)
+- Fixes for race conditions (the behavior was previously indeterminate so less of an argument against it changing)
+- Data corruption fixes - on a case by case basis if they change existing query results.
+- Missing functionality that prevents features from working.
+- Changes for tech-preview work that only effect those who are using it.
+- Regressions.
+- Improvements to logging and error messages (possibly in "previous" if simple and added to help diagnose problems).
+- Occasional simple refactoring that makes up-merging simpler..
+- Changes to improve backward compatibility of new features. (E.g. adding an ignored syntax to the compiler.)
+- Performance improvements - if simple and safe
+
+"previous":
+- Simple bug fixes that do not change behavior
+- Simple changes for missing functionality
+- Regressions with simple fixes (but care is needed if it caused a change in behavior)
+- Serious regressions
+- Complex security fixes
+
+"critical" fixes only:
+- Simple security fixes
+- Complex security fixes if sufficiently serious
+
+"security" fixes only:
+- Serious security fixes
+
+early:
+- The first few point release of a new major or minor version may be less stable than later point releases.  The security fix is still supported until any teething problems have been solved with the new version.
+
+Occasionally earlier branches will be chosen, (e.g. security fixes to even older versions) but they should always be carefully discussed (and documented).
+
+## Patches and images
+
+We aim to produce new point releases once a week.  The point releases will contain
+
+a) Any changes to the code base for that branch.
+b) Any security fixes for libraries that are project dependencies.  We will upgrade to the latest point release for the library that fixes the security issue.
+c) For the cloud any security fixes in the base image or the packages installed in that image.
+
+If there are no changes in any of those areas for a particular version then a new point release will not be created.
+
+If you are deploying a system to the cloud you have one of two options
+
+a) Use the images that are automatically built and published as part of the build pipeline.  This image is currently based on ubuntu 22.04 and contains the majority of packages users will require.
+
+b) Use your own hardened base image, and install the containerized package that we publish into that image.
+
+## Package versions.
+
+We currently generate the following versions of the package and images:
+
+- debug
+- release with symbols
+- release without symbols.
+
+It is recommended that you deploy the "release with symbols" version to all bare-metal and non-production cloud deployments.  The extra symbols allow the system to generate stack backtraces which make it much easier to diagnose problems if they occur.
+The "release without symbols" version is recommended for Kubernetes production deployments.  Deploying a system without symbols reduces the size of the images.  This reduces the time it takes Kubernetes to copy the image before provisioning a new node.

devdoc/roxie.md

@@ -263,7 +263,7 @@ There are a number of potential questions and issues with this code:
 10. Does the "reconnect" attempt from the deblacklister cause any pain for the server it is connecting to? Lots of connect attempts without any data
     could look like a DoS attack...
 11. Retries/timeout seems to translate to
-        Owned<ISocketConnectWait> scw = nonBlockingConnect(ep, timeoutMS == WAIT_FOREVER ? 60000 : timeoutMS*(retries+1));
+        `Owned<ISocketConnectWait> scw = nonBlockingConnect(ep, timeoutMS == WAIT_FOREVER ? 60000 : timeoutMS*(retries+1));`
     I am not sure that is correct (a single attempt to connect with a long timeout doesn't feel like it is the same as multiple attempts with shorter
     timeouts, for example if there is a load balancer in the mix).
 11. Perhaps an option to not use blacklister would solve the immediate issue?

esp/CMakeLists.txt

@@ -30,6 +30,7 @@ HPCC_ADD_SUBDIRECTORY (test "PLATFORM")
 HPCC_ADD_SUBDIRECTORY (tools "CLIENTTOOLS")
 HPCC_ADD_SUBDIRECTORY (xslt)
 HPCC_ADD_SUBDIRECTORY (esdllib)
+HPCC_ADD_SUBDIRECTORY (esdlscriptlib)
 HPCC_ADD_SUBDIRECTORY (applications)
 HPCC_ADD_SUBDIRECTORY (espcommon)
 if (LOGGING_SERVICE)