From: Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] say: fix format for fiber()->fid Date: Wed, 24 Feb 2021 00:49:21 +0300 [thread overview] Message-ID: <YDV4YV1ieU/JZW+9@grain> (raw) In-Reply-To: <41811c65-448c-0de6-68cd-6a64779ca283@tarantool.org> On Tue, Feb 23, 2021 at 09:41:46PM +0100, Vladislav Shpilevoy wrote: > Hi! Please, add a changelog file. This is user-visible behaviour > so it must be reflected in the changes. > > On 22.02.2021 19:20, Cyrill Gorcunov wrote: > > The fiber's ID (fiber::fid) is unsigned integer so > > we should use a proper format specificator when printing > > it out, otherwise the logger show us weird strings like > > > > | main/-244760339/cartridge.failover.task I> Instance state changed > > > > Fixes #5846 > > > > Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> > > --- > > src/lib/core/say.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/src/lib/core/say.c b/src/lib/core/say.c > > index cbd10e107..6138752a7 100644 > > --- a/src/lib/core/say.c > > +++ b/src/lib/core/say.c > > @@ -792,7 +792,7 @@ say_format_plain_tail(char *buf, int len, int level, const char *filename, > > if (cord) { > > SNPRINT(total, snprintf, buf, len, " %s", cord->name); > > if (fiber() && fiber()->fid != FIBER_ID_SCHED) { > > - SNPRINT(total, snprintf, buf, len, "/%i/%s", > > + SNPRINT(total, snprintf, buf, len, "/%u/%s", > > fiber()->fid, fiber_name(fiber())); > > I remember we had some issues about %u not being compatible with uint32_t so > we did manual casts to 'unsigned'. Not sure though what was the commit/ticket, > or if it really happened. I suspect you rather mean uint64_t, which indeed better convert to excplicit "long long". Strictly speaking if we really need to cover compatibility we would _had_ to use PRIx macros which are so ugly :/ So no, uint32_t is known to be safe with %u format. Side note: I found that we still use %u for some of uint64_t, in particuar if (req->term < raft->volatile_term) { say_info("RAFT: the message is ignored due to outdated term - " "current term is %u", raft->volatile_term); return 0; } probably should use %llu and explicit "long long" for long standing servers where raft term would overflow 32 bit value. > > I am fine with not using the cast as long as all platforms and compilers > build flawlessly. Also it is ok for me if you will add an explicit cast in > the next version of the patch. Up to you. The same below. No, Vlad, I think we don't need explicit casts for 32bit values. I pushed an update to the branch gorcunov/gh-5846-fid-name and here is a new changelog. Does it look better? --- Subject: [PATCH] say: use unsigned format for fiber()->fid The fiber's ID (fiber::fid) is defined as unsigned integer so we should use a proper format specificator when printing it out. Currently logger prints such fibers as negative | main/-244760339/cartridge.failover.task I> Instance state changed why it should be | main/4271292179/cartridge.failover.task I> Instance state changed After the fix all fibers are logged with natural numbers (both in plain logger and json output formats) which might be considered as API change but should not cause any problems because if there were tools which scans for "zahlen" numbers they will scan for natural numbers without problems. After all there is no such things as fibers with negative numbers and when their fids are printed in Lua's "info" they are all natural (because they are converted into real numbers internally). Fixes #5846
next prev parent reply other threads:[~2021-02-23 21:49 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-22 18:20 Cyrill Gorcunov via Tarantool-patches 2021-02-22 18:23 ` Cyrill Gorcunov via Tarantool-patches 2021-02-23 20:41 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-23 21:49 ` Cyrill Gorcunov via Tarantool-patches [this message] 2021-02-23 22:47 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-24 8:28 ` Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:39 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 00/10] say: fix format strings Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 01/10] say: use unsigned format for fiber()->fid Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 02/10] popen: fix say_x format arguments Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:39 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-25 7:27 ` Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 03/10] raft: fix say_x arguments Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:39 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-25 7:50 ` Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 04/10] box/error: fix argument for CustomError Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 05/10] xlog: fix say_x format Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:40 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 06/10] box/vynil: " Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:43 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-26 8:13 ` Nikita Pettik via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 07/10] txn: " Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 08/10] limbo: " Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 09/10] wal: " Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:41 ` Vladislav Shpilevoy via Tarantool-patches 2021-02-25 7:52 ` Cyrill Gorcunov via Tarantool-patches 2021-02-24 15:36 ` [Tarantool-patches] [PATCH v2 10/10] say: fix CFORMAT specification Cyrill Gorcunov via Tarantool-patches 2021-02-24 22:41 ` Vladislav Shpilevoy via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YDV4YV1ieU/JZW+9@grain \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH] say: fix format for fiber()->fid' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox