[Lldb-commits] [lldb] [lldb] Adds additional fields to ProcessInfo (PR #91544)

Fred Grim via lldb-commits lldb-commits at lists.llvm.org
Mon May 13 09:23:34 PDT 2024


================
@@ -147,96 +148,111 @@ class ProcessInstanceInfo : public ProcessInfo {
   ProcessInstanceInfo() = default;
 
   ProcessInstanceInfo(const char *name, const ArchSpec &arch, lldb::pid_t pid)
-      : ProcessInfo(name, arch, pid), m_euid(UINT32_MAX), m_egid(UINT32_MAX),
-        m_parent_pid(LLDB_INVALID_PROCESS_ID) {}
+      : ProcessInfo(name, arch, pid) {}
 
   void Clear() {
     ProcessInfo::Clear();
-    m_euid = UINT32_MAX;
-    m_egid = UINT32_MAX;
-    m_parent_pid = LLDB_INVALID_PROCESS_ID;
+    m_euid = std::nullopt;
+    m_egid = std::nullopt;
+    m_parent_pid = std::nullopt;
   }
 
-  uint32_t GetEffectiveUserID() const { return m_euid; }
+  uint32_t GetEffectiveUserID() const { return m_euid.value(); }
----------------
feg208 wrote:

I don't have particularly strong feelings here but we should keep it consistent between this class and the parent class which has GetUID and GetGID neither of which returns a std::optional. Given the risk of std::bad_optional_access getting thrown thoughout I am coming to the notion that maybe we shouldn't use optionals here? If we have optionals I guess we are mandating that the paired IsValid must exist and must always be called. That seems like it'll create challenges. Can we go back to using invalid values like UINT32_MAX and maybe alter the interface to use optionals in a subsequent pr? This way we could debate the merits of this approach independent of adding a niceness field. 

https://github.com/llvm/llvm-project/pull/91544


More information about the lldb-commits mailing list