================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
