From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 5 Apr 2019 16:43:20 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH v2] xrow: print corrupted rows on decoding error. Message-ID: <20190405134320.2j6utjziiwtmowxq@esperanza> References: <20190401130906.31356-1-sergepetrenko@tarantool.org> <20190403091827.qh5rxxpsbrkl35bp@esperanza> <338F2586-287A-4521-A6EE-F9E738FF6701@tarantool.org> <20190404120637.x7s5bulkubcaqweh@esperanza> <20190404145110.7mqil2sf6pmcfkn4@esperanza> <20190405061846.GA24274@chai> <20190405080608.uyuunti2tebak5wl@esperanza> <20190405132015.GA1687@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190405132015.GA1687@chai> To: Konstantin Osipov , Serge Petrenko Cc: tarantool-patches@freelists.org, Kirill Yukhin List-ID: On Fri, Apr 05, 2019 at 04:20:15PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [19/04/05 16:11]: > > > But provided you had to write your own implementation: > > > - why use a macro? > > > > So that diag_set() and say() preserve file/line. > > You inline the macro multiple times. This makes the function body > longer -> CPU job more difficult. You could easily pass file and > line into the function, these are ansi c standard macros, __FILE__ > and __LINE__ You're right. Let's move print to a helper function then. > > > > > - why use malloc? > > > > Because a corrupted request can easily be longer than 256 bytes (that's > > how many bytes fits in tt_static_buf). Since it's a slow path, which is > > only executed on decode error provided S_VERBOSE log level is enabled, > > I reckon using malloc() is fine. > > It's 1024 bytes. > What's the point of printing it as a single say() call, not as > multiple ones? > > Besides, there is a 4k buffer inside say which limits you anwyay. Makes sense. Sergey, please prepare a follow-up patch to fix these issues.