On Wed, 2018-08-22 at 11:47 +0200, Christophe Fergeau wrote: > On Wed, Aug 22, 2018 at 11:46:59AM +0200, Christophe Fergeau wrote: > > Hey, > > > > On Tue, Aug 21, 2018 at 05:30:50PM +0200, Jakub Jelen wrote: > > > On Tue, 2018-08-21 at 17:03 +0200, Christophe Fergeau wrote: > > > > hex_dump() callers can theoretically provide the destination > > > > buffer > > > > for the hexdump'ed string, but nothing in libcacard uses that > > > > feature. > > > > This commit removes it. > > > > > > The initial idea was to create some g_debug_hex function that > > > could use > > > that with dynamic allocation, but that never happened. It does > > > not make > > > sense to ship dead code. > > > > On the dynamic allocation front, I experimented with > > https://gitlab.com/teuf/libcacard/commit/472ad2e6df31472120e0d22d > > together with a DUMP_BUFFER macro wrapping the allocation/freeing > > of the > > buffer, but still unsure this is the right way forward... ;) > > Forgot to mention, Frediano pointed out the current approach with a > static buffer would have issues if called from multiple threads. Its a question, if we care. The hex_dump() function is accessed only from debug functions now (usually testsuite). Additionally, I don't think qemu is using libcacard from more threads at a time. Even if it would be, the requests are in the end queued and serially handled by the card emulator so I don't think this would be an issue now or later. Regards, Jakub _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel