Re: [Check-devel] ck_assert_hex_eq

[Branden A. <b.m...@gm...>]

> launch the specified command (eg 'diff') to allow the user to inspect
what changed

Having a mechanism for helping a developer determine the failure is
helpful. I wonder though if something like dumping the contents to a file
and running diff would be a bit much. Although one may be running a test in
isolation, it may be more likely that there are many tests which are run.
This would result in many temp files and runs of diff. It may be more
direct if the developer instruments the test(s) in question such that it
dump the contents being checked for further inspection.

Besides that, I am wondering how the feature could be cross-platform.
Linux/Unix I am familiar with, but it would be a little more effort to get
Windows working.

Not shooting down the idea. Just thinking through it. How useful would it
be for your use case, and how would the output of the diff command relate
to Check's logging? Would the output only be available in some of Check's
logging types?

- Branden

On Sun, Nov 27, 2016 at 4:11 PM, Nicholas Humfrey <nj...@ae...> wrote:

> Just when I really need this functionality and start to think about
> implementing it, I find that someone has already done the work in the
> form of ck_assert_mem_*. Laziness is rewarded!
>
> For those who having seen, ck_assert_mem_eq, test_ck_assert_mem_ne was
> merged into master on Nov 3:
> https://github.com/libcheck/check/commit/908497153ccbf91169e6e4de76dab1
> 9ab1103464
>
> Something that would enhance this would be to have better tooling to
> work out what the differences are when a test fails. What do you think
> about having a CK_DIFF_TOOL environment variable, which when set would
> create two temporary files containing the expected and actual outputs in
> hex, launch the specified command (eg 'diff') to allow the user to
> inspect what changed?
>
> I am personally using ck_assert_mem_eq to verify that a generated
> Ethernet frame/packet matches what it should, so less than 1500 bytes
> but quite a bit more than CK_MAX_ASSERT_MEM_PRINT_SIZE, which defaults
> to 64 bytes.
>
>
> nick.
>
>
>
> On 2016-07-31 14:42, Nicholas Humfrey wrote:
> > Thanks for the advice Chris.
> >
> > I will give it ago - need to get the balance right between being overly
> > complex to implement and being useful. Will see if there is something
> > that compares binaries that I can steal.
> >
> > nick.
> >
> >
> > On 2016-07-31 00:02, Chris Pickett wrote:
> >> Hi Nick,
> >>
> >> It sounds fine to me.  How about if you get it working for your own
> >> project and then show us what it looks like?  For a long enough buffer
> >> you'll want some kind of start offset plus a window that starts before
> >> the differences and finishes after them.  Maybe somebody has already
> >> built a nice bindiff?  It could be fiddly, consider if there are
> >> multiple bits of the binary that differ.  I'm not sure but bin_eq
> >> might be a better name than hex_eq.
> >>
> >> Chris
> >>
> >> Nicholas Humfrey wrote:
> >>> Hello,
> >>>
> >>> I have been working on project that has tests that do quite a bit of
> >>> comparing between binary buffers. I have thought that a
> >>> ck_assert_hex_eq() assertion would be useful, that compares two
> >>> pointers and displays the difference, in hex, if they are not equal.
> >>>
> >>> ck_assert_hex_eq(X, Y, len);
> >>>
> >>> Internally it would use memcmp() to perform the comparison.
> >>> The complexity would be in printing the difference as hex.
> >>>
> >>>
> >>> Would there be any interest in me contributing something like this to
> >>> check?
> >>>
> >>>
> >>> nick.
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> _______________________________________________
> >>> Check-devel mailing list
> >>> Che...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/check-devel
> >
> >
> > ------------------------------------------------------------
> ------------------
> > _______________________________________________
> > Check-devel mailing list
> > Che...@li...
> > https://lists.sourceforge.net/lists/listinfo/check-devel
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Check-devel mailing list
> Che...@li...
> https://lists.sourceforge.net/lists/listinfo/check-devel
>