From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 17D4B385AC33 for ; Tue, 16 Nov 2021 15:10:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 17D4B385AC33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A2C411E940; Tue, 16 Nov 2021 10:10:23 -0500 (EST) Subject: Re: [PATCHv6 3/3] gdb/python: add gdb.RemoteTargetConnection.send_packet To: Andrew Burgess , gdb-patches@sourceware.org References: <1ee3ff1661f4e29adb8cf1daf90f88bd7c282a77.1636997240.git.aburgess@redhat.com> <20211116124847.GJ2352@redhat.com> From: Simon Marchi Message-ID: <30f85ce3-b785-d7e7-5356-30b8822225a4@simark.ca> Date: Tue, 16 Nov 2021 10:10:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211116124847.GJ2352@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2021 15:10:27 -0000 On 2021-11-16 7:48 a.m., Andrew Burgess via Gdb-patches wrote: > Simon, Eli, > > Thanks for the feedback, I think I've addressed everything in this > update. > > Simon, sorry for not quite getting your point the first time through. > I believe that this revision should address your concerns. I have not > been as restrictive as you suggested, but hopefully this should still > be acceptable. > > So, you can still pass a string, but the documentation is specific > that it must be possible to convert the string to a bytes object using > the ascii codec. This allows for what I assume would be the most > common use case: > > conn.send_packet("some_ascii_text") > > But if we revisit your example, we now get: > > res = conn.send_packet('X555555558028,4:\xff\x03\x02\xff') > UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 10: ordinal not in range(128) > > In which case, the solution is, as your suggest, to pass a bytes > object: > > res = conn.send_packet(b'X555555558028,4:\xff\x03\x02\xff') > print(res) > b'OK' > > I've tested this code with Python 3.7 and Python 2.7 and it seems to > work fine. I've extended the test to include your example and related > cases, hopefully that should cover what I've said above. > > Let me know what you think, If I had done it myself, I would have accepted just "bytes" objects, to be more straightforward in the implementation and the doc. But I am still happy with what you have, the user won't have sneaky encoding bugs. So, +1 from me. Simon