Tarantool development patches archive
 help / color / mirror / Atom feed
From: Igor Munkin via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Sergey Kaplun <skaplun@tarantool.org>
Cc: Sergey Bronnikov <estetus@gmail.com>,
	max.kokryashkin@gmail.com, tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH luajit 1/2] test: introduce asserts assert_str{_not}_equal
Date: Wed, 1 Nov 2023 08:28:37 +0000	[thread overview]
Message-ID: <ZUIMNddwFvQ9RIq_@tarantool.org> (raw)
In-Reply-To: <ZUIA8ZwggVy6xHmu@root>

Sergey,

On 01.11.23, Sergey Kaplun via Tarantool-patches wrote:
> Hi, Sergey!

<snipped>

> 
> If some test fails we got the following output:
> 
> | TAP version 13
> | 1..1
> | not ok 1 - lua_concat_testcase
> |   ---
> |   location:     /home/burii/reviews/luajit/lj-881-lua-concat/test/tarantool-c-tests/lj-881-fix-lua-concat.test.c:81
> |   failed_assertion:     assert_str_equal
> |   got: 1652880104
> |   expected: -1138225337
> |   ...
> | # Failed 1 tests out of 1
> 
> Failed assertion field is incorrect (see the comment above).
> But the most important is "got" and "expected" fields, that returns the
> addresses of strings, which isn't very meaningful.
> 
> I suggest dumping the strings instead if they are not long enough (less
> than 128 symbols, I suppose). The maxdump string length should be
> a customizeable parameter. I suggest defining a macro `MAX_DUMP_STRLEN`
> inside the <test.h> header. So the user can redefine it before the
> `assert_str_{not_}equal()` and use a custom value.
> 
> If the string is too long, we should dump the offset of the mismatched
> symbol. Or maybe it's better to always dump it.
> 
> Thoughts?

What if the different part starts after 128 symbols? I believe the most
valuable part is the one where the difference starts, so you have to
dump the beginning (for convenience), the difference and some numeric
parameters (length, offset where strings differ, etc).

Furthermore, I suggest implementing <*_str_*> helpers for nul-terminated
strings and <*_mem_*> helpers for length limited memory blobs.

> 
> Side note:
> 
> Also, this comparing "by eye" isn't very convenient if values aren't
> aligned, so maybe it is better to use spaces instead of tabs to align
> values? This may be added within the separate patch series later.

I believe, this is quite minor thing (at least for now).

> 

<snipped>

> 
> -- 
> Best regards,
> Sergey Kaplun

-- 
Best regards,
IM

  reply	other threads:[~2023-11-01  8:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1698775628.git.sergeyb@tarantool.org>
2023-09-26  6:56 ` [Tarantool-patches] [PATCH luajit] LJ_GC64: Fix lua_concat() Sergey Bronnikov via Tarantool-patches
2023-09-29  8:24   ` Maxim Kokryashkin via Tarantool-patches
2023-10-03 15:35     ` Sergey Bronnikov via Tarantool-patches
2023-10-04 10:48       ` Maxim Kokryashkin via Tarantool-patches
2023-10-06 13:51         ` Sergey Bronnikov via Tarantool-patches
2023-10-31 18:11   ` [Tarantool-patches] [PATCH luajit 1/2] test: introduce asserts assert_str{_not}_equal Sergey Bronnikov via Tarantool-patches
2023-11-01  7:40     ` Sergey Kaplun via Tarantool-patches
2023-11-01  8:28       ` Igor Munkin via Tarantool-patches [this message]
2023-11-10 11:41         ` Sergey Bronnikov via Tarantool-patches
2023-11-14  8:55           ` Sergey Kaplun via Tarantool-patches
2023-11-15  9:32             ` Sergey Bronnikov via Tarantool-patches
2023-11-16  8:02               ` Sergey Kaplun via Tarantool-patches
2023-11-18 16:40                 ` Sergey Bronnikov via Tarantool-patches
2023-11-20  9:28                   ` Sergey Kaplun via Tarantool-patches
2023-11-20 13:19                   ` Igor Munkin via Tarantool-patches
2023-11-10 11:40       ` Sergey Bronnikov via Tarantool-patches
2023-11-23  6:31   ` [Tarantool-patches] [PATCH luajit] LJ_GC64: Fix lua_concat() Igor Munkin 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=ZUIMNddwFvQ9RIq_@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=estetus@gmail.com \
    --cc=imun@tarantool.org \
    --cc=max.kokryashkin@gmail.com \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit 1/2] test: introduce asserts assert_str{_not}_equal' \
    /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