[Lldb-commits] [lldb] [lldb][gdb-remote] Forward client terminal size to lldb-server (PR #201141)

[David Spickett via lldb-commits]

================
@@ -963,6 +966,33 @@ GDBRemoteCommunicationServerCommon::Handle_QSetSTDERR(
   return SendErrorResponse(17);
 }
 
+GDBRemoteCommunication::PacketResult
+GDBRemoteCommunicationServerCommon::Handle_QSetSTDIOWindowSize(
+    StringExtractorGDBRemote &packet) {
+  // Format: "QSetSTDIOWindowSize:cols=N;rows=N"
+  packet.SetFilePos(::strlen("QSetSTDIOWindowSize:"));
+  llvm::StringRef body = packet.GetStringRef().substr(packet.GetFilePos());
+
+  uint16_t cols = 0;
+  uint16_t rows = 0;
+  llvm::SmallVector<llvm::StringRef, 4> fields;
+  body.split(fields, ';');
+  for (llvm::StringRef field : fields) {
+    auto [key, value] = field.split('=');
+    unsigned parsed = 0;
+    if (value.empty() || value.getAsInteger(10, parsed) || parsed > UINT16_MAX)
----------------
DavidSpickett wrote:

This is not a problem in practice, but I think this is more readable if you check for known keys first, then parse the value.

Right now, you have 2 keys that happen to be of the same type, but if we extended this in future with a string value, you'd have to refactor it anyway to check keys first, then value types depending on that.

Doing value first also means that you'd try to parse as integers the values for unknown keys. So if this code is in an existing binary but is sent a newly extended packet, it would waste some cycles parsing values for keys it didn't know how to use.

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