Commit Graph

65 Commits

Author SHA1 Message Date
Ripose 34cfe9d89b command: add secondary-sub-start and secondary-sub-end properties
Adds secondary-sub-start and secondary-sub-end properties by setting
the current_track index in the m_property's priv variable which later
gets accessed in get_times. Also adds a test of the secondary subtitle
time properties in tests/subtimes.js bound to 'T'.
2021-07-12 21:07:37 +00:00
wm4 0279a44d93 command: extend subprocess command
Add env and detach arguments. This means the command.c code must use the
"new" mp_subprocess2(). So also take this as an opportunity to clean up.
win32 support gets broken by it, because it never made the switch to the
newer function.

The new detach parameter makes the "run" command fully redundant, but I
guess we'll keep it for simplicity. But change its implementation to use
mp_subprocess2() (couldn't do this earlier, because win32).

Privately, I'm going to use the "env" argument to add a key binding that
starts a shell with a FILE environment variable set to the currently
playing file, so this is very useful to me.

Note: breaks windows, so for example youtube-dl on windows will not work
anymore. mp_subprocess2() has to be implemented. The old functions are
gone, and subprocess-win.c is not built anymore. It will probably work
on Cygwin.
2020-07-20 21:02:17 +02:00
wm4 2a89da0c85 zimg: add slice threading and use it by default
This probably makes it much faster (I wouldn't know, I didn't run any
benchmarks ). Seems to work as well (although I'm not sure, it's not
like I'd perform rigorous tests).

The scale_zimg test seems to mysteriously treat color in fully
transparent alpha differently, which makes no sense, and isn't visible
(but makes the test fail). I can't be bothered with investigating this
more. What do you do with failing tests? Correct, you disable them. Or
rather, you disable whatever appears to cause them to fail, which is the
threading in this case.

This change follows mostly the tile_example.cpp. The slice size uses a
minimum of 64, which was suggested by the zimg author. Some of this
commit is a bit inelegant and weird, such as recomputing the scale
factor for every slice, or the way slice_h is managed. Too lazy to make
this more elegant.

zimg git had a regressio around active_region (which is needed by the
slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the
bug was never released, so just add a warning to the manpage.
2020-07-15 22:59:17 +02:00
wm4 1ffa83ea92 test: update to new ffmpeg pixfmts
Mainly, X2RGB10BE is added. Add our own unpack test for this format.
Also, swscale seems to have added support for GBRPF conversion.
2020-06-17 19:43:09 +02:00
wm4 320fa3bbe7 video: add AV_PIX_FMT_UYYVYY411 conversion support
It may be completely useless, and I can't verify it as no known samples
or other known/accessible software using it, but why not?

Putting this together with he 422 code requires making it slightly more
generic. I'm still staying with a "huge" if tree instead of a table to
select the scanline worker callback, because it's actually small and not
huge (although it not being generic still feels slightly painful).
2020-05-22 02:26:05 +02:00
wm4 086953a9da video: clean up pixel metadata stuff some more
A repeat of the previous useless commits.

Pondered whether to use separate fields or just a flags integer for
color and component types; the latter won for now.

Functions like mp_imgfmt_get_component_type() are now discouraged, and
mp_imgfmt_desc.flags is back for defining all information. Some days ago
I felt like the opposite would be the better design. Fortunately, it
doesn't matter.

With this, I think all image format properties that mpv needs are
exhaustively defined all in one place.
2020-05-20 18:38:15 +02:00
wm4 176f422213 video: shuffle imgfmt metadata code around
I guess I decided to stuff it all into mp_imgfmt_desc (the "old"
struct). This is probably a mistake. At first I was afraid that this
struct would get too fat (probably justified, and hereby happened), but
on the other hand mp_imgfmt_get_desc() (which builds the struct) calls
the former mp_imgfmt_get_layout(), and the separation doesn't make too
much sense anyway. Just merge them.

Still, try to keep out the extra info for packed YUV bullshit. I think
the result is OK, and there's as much information as there was before.

The test output changes a little. There's no independent bits[] array
anymore, so formats which did not previously have set this now show it.
(These formats are mpv-only and are still missing the metadata. To be
added later). Also, the output for the cursed packed formats changes.
2020-05-20 00:02:27 +02:00
wm4 2256a9e42b video: fix AV_PIX_FMT_UYYVYY411 allocation
My previous commit added support for this format, but it was still
broken, and prevented the allocation code from working. It's unknown
whether it's correct now (because this pixfmt is so obscure and useless,
there are no known samples around), but who cares.
2020-05-18 19:29:25 +02:00
wm4 27e5416c12 video: add pixel component location metadata
I thought I'd probably want something like this, so the hardcoded stuff
in repack.c can be removed eventually. Of course this has no purpose at
all, and will not have any. (For now, this provides only metadata, and
nothing uses it, apart from the "test" that dumps it as text.)

This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite,
because the format is 100% useless). Support for some mpv-only formats
is missing, ironically.

The code goes through _lengths_ to try to make sense out of the FFmpeg
AVPixFmtDescriptor data. Which is even more amazing that the new
metadata basically mirrors pixdesc, and just adds to it. Considering
code complexity and speed issues (it takes time to crunch through all
this shit all the time), and especially the fact that pixdesc is very
_incomplete_, it would probably better to have our own table to all
formats. But then we'd not scramble every time FFmpeg adds a new format,
which would be annoying. On the other hand, by using pixdesc, we get the
excitement to see whether this code will work, or break everything in
catastrophic ways.

The data structure still sucks a lot. Maybe I'll redo it again. The text
dump is weirdly differently formatted than the C struct - because I'm
not happy with the representation. Maybe I'll redo it all over again.

In summary: this commit does nothing.
2020-05-18 01:54:59 +02:00
wm4 caee8748da video: clean up some imgfmt related stuff
Remove the vaguely defined plane_bits and component_bits fields from
struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove
the bytes[] field, replace uses with bpp[].

Fix some potential alignment issues in existing code. As a compromise,
split mp_image_pixel_ptr() into 2 functions, because I think it's a bad
idea to implicitly round, but for some callers being slightly less
strict is convenient.

This shouldn't really change anything. In fact, it's a 100% useless
change. I'm just cleaning up what I started almost 8 years ago (see
commit 00653a3eb0). With this I've decided to keep mp_imgfmt_desc,
just removing the weird parts, and keeping the saner parts.
2020-05-18 01:54:59 +02:00
wm4 00ac63c37b test: explicitly test repacking for all packed RGB variants
This stuff is very annoying, so it's good to have full coverage.
2020-05-18 01:54:59 +02:00
wm4 baabd5fce3 draw_bmp: use command line options for any used scalers 2020-05-13 20:07:59 +02:00
wm4 0ff839d467 draw_bmp: add integer blending for 8 bit formats
Whatever it's worth. Instead of doing a pretty stupid conversion to
float, just blend it directly. This works for most RGB formats that are
8 bits per component or below (the latter because we expand packed
fringe RGB formats for simplicity). For higher bit depth RGB this would
need extra code.
2020-05-12 23:10:14 +02:00
wm4 c4b2ca83d6 draw_bmp: don't make strange decisions on broken iknput csp params
This checked params->color.space for being RGB. If the colorspace is
unset, this did dumb things because even if the imgfmt was a RGB one,
the colorspace was not set to RGB. This actually also happened to the
tests.

(Short-cutting RGB like this is actually wrong, since RGB could still
have strange gamma or primaries, which would warrant a full conversion.
So you'd need to check for these other parameters as well. To be fixed
later.)
2020-05-12 22:43:29 +02:00
wm4 55e1f15cdb draw_bmp: add a function to return a single-texture OSD overlay
Maybe this is useful for some of the lesser VOs. It's preferable over
bad ad-hoc solutions based on the more complex sub_bitmap data
structures (as observed e.g. in vo_vaapi.c), and does not use that much
more code since draw_bmp already created such an overlay internally.

But I still wanted something that avoids having to upload/render a full
screen-sized overlay if for example there's only a tiny subtitle line on
the bottom of the screen. So the new API can return a list of modified
pixels (for upload) and non-transparent pixels (for display). The way
these pixel rectangles are computed is a bit dumb and returns dumb
results, but it should be usable, and the implementation can change.
2020-05-11 19:57:34 +02:00
wm4 c1a961ad78 draw_bmp: rewrite
draw_bmp.c is the software blender for subtitles and OSD. It's used by
encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11,
vo_xv, and possibly more.

This changes the algorithm from upsampling the video to 4:4:4 and then
blending to downsampling the OSD and then blending directly to video.
This has far-reaching consequences for its internals, and results in an
effective rewrite.

Since I wanted to avoid un-premultiplying, all blending is done with
premultiplied alpha. That's actually the sane thing to do. The old code
just didn't do it, because it's very weird in YUV fixed point.
Essentially, you'd have to compensate for the chroma centering constant
by subtracting src_alpha/255*128. This seemed so hairy (especially with
correct rounding and high bit depths involved) that I went for using
float.

I think it turned out mostly OK, although it's more complex and less
maintainable than before. reinit() is certainly a bit too long. While it
should be possible to optimize the RGB path more (for example by
blending directly instead of doing the stupid float conversion), this is
probably slower. vo_xv users probably lose in this, because it takes the
slowest path (due to subsampling requirements and using YUV).

Why this rewrite? Nobody knows. I simply forgot the reason. But you'll
have it anyway. Whether or not this would have required a full rewrite,
at least it supports target alpha now (you can for example hard sub
transparent PNGs, if you ever wanted to use mpv for this).

Remove the check in vf_sub. The new draw_bmp.c is not as reliant on
libswscale anymore (mostly uses repack.c now), and osd.c shows an
error message on missing support instead now.

Formats with chroma subsampling of 4 are not supported, because FFmpeg
doesn't provide pixfmt definitions for alpha variants. We could provide
those ourselves (relatively trivial), but why bother.
2020-05-09 18:02:57 +02:00
wm4 9190b3c469 repack: add support for converting from/to float formats
Will be needed by draw_bmp.c. The tests cross-check this with zimg to
control whether we're getting it right.
2020-05-09 18:02:57 +02:00
wm4 56dbbc3847 video: add yuv float formats
Adding all these so I can use them for obscure processing purposes (see
later draw_bmp commit).

There isn't really a reason why they should exist. On the other hand,
they're just labels for formats that can be handled in a generic way,
and this commit adds support for them in the zimg wrapper and vo_gpu
just by making the formats exist. (Well, vo_gpu had to be fixed in the
previous commit.)
2020-05-09 18:02:57 +02:00
wm4 4019c11314 video: fix rgb30 component order
Was broken with a zimg wrapper refucktor before the previous commit. In
addition, it seems this didn't match the vo_drm format, or the format
naming convention. So the order actually changes, and the format is
redefined. (The img_format.h comment was probably wrong.)

Change vo_gpu to the new format as well, so we can still test it.
2020-05-09 18:02:57 +02:00
wm4 d8002f1dde video: separate repacking code from zimg and make it independent
For whatever purpose. If anything, this makes the zimg wrapper cleaner.

The added tests are not particular exhaustive, but nice to have. This
also makes the scale_zimg.c test pretty useless, because it only tests
repacking (going through the zimg wrapper). In theory, the repack_tests
things could also be used on scalers, but I guess it doesn't matter.

Some things are added over the previous zimg wrapper code. For example,
some fringe formats can now be expanded to 8 bit per component for
convenience.
2020-05-09 18:02:57 +02:00
wm4 e567d06377 test: fix some idiotic UB 2020-05-06 15:27:25 +02:00
wm4 28e4fe3010 img_format: treat both monow and monob as RGB
This was inconsistent for unknown reason. monob was the way we wanted
it, and handling of monow was missing.

See the previous "img_format: add some mpv-only helper formats" commit.

Matters for the zimg wrapper.
2020-04-23 13:24:35 +02:00
wm4 8767c46873 img_format: add some mpv-only helper formats
Utterly useless, but the intention is to make dealing with corner case
pixel formats (forced upon us by FFmpeg, very rarely) less of a pain.
The zimg wrapper will use them. (It already supports these formats
automatically, but it will help with its internals.)

Y1 is considered RGB, even though gray formats are generally treated as
YUV for various reasons. mpv will default all YUV formats to limited
range internally, which makes no sense for a 1 bit format, so this is a
problem. I wanted to avoid that mp_image_params_guess_csp() (which
applies the default) explicitly checks for an image format, so although
a bit janky, this seems to be a good solution, especially because I
really don't give a shit about these formats, other than having to
handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray,
just packed) already explicitly marked itself as RGB.
2020-04-23 13:24:35 +02:00
wm4 0f8f6a665b video: change chroma_w/chroma_h fields to use shift instead of size
When I added mp_regular_imgfmt, I made the chroma subsampling use the
actual chroma division factor, instead of a shift (log2 of the actual
value). I had some ideas about how this was (probably?) more intuitive
and general. But nothing ever uses non-power of 2 subsampling (except
jpeg in rare cases apparently, because the world is a bad place).

Change the fields back to use shifts and rename them to avoid mistakes.
2020-04-23 13:24:35 +02:00
wm4 7cb83593c2 img_format: add format description table for mpv-only formats
Make this slightly less ad-hoc. Also correct the missing alpha flag for
yap8/yap16.

Despite reduced redundancy, the LOC is going up anyway... whatever.
2020-04-23 13:24:35 +02:00
wm4 7832204c99 zimg: add support for 1 bit per pixel formats
Again worthless, slow, and only for libswscale parity.

With this, we support all formats libswscale supports, except bayer
input, and rgb4/bgr4 output. We even support some formats libswscale
doesn't.

It's possible that the zimg wrapper isn't always as fast as libswscale.
But there is optimization potential: the inner repack loops are
self-contained enough that they could be reasonably be implemented in
assembler (probably), and doing everything slice-wise should reduce the
overhead of the separate pack/unpack stages.
2020-04-13 20:42:34 +02:00
wm4 afedaf3b61 zimg: add packed YUV bullshit
Just lazily tested.

The comment on AV_PIX_FMT_Y210LE seems to be wrong. It claims it's "like
YUYV422", bit it seems more like YVYU422, at last the way libswscale
input treats it. Maybe Intel pays its developers too much?

The repacker inner lop is probably rather inefficient. In theory we
could optimize it by reading the packed pixels as words, doing the
component reshuffling using compile time values etc., but I'd rather
keep the code size small. It's already bad enough that we have to
support 16 bit per component variants, just because this one Intel guy
couldn't keep it in his pants. In general, I can't be bothered to spend
time on optimizing it; I'm only doing this for fun (i.e. masochistic
obligation).
2020-04-13 20:05:38 +02:00
wm4 56cac2be46 test: add list of zimg/sws conversions
Generic statement about how this is not really appropriate, etc., and
only useful for temporary debugging things, and how I commit it anyway
despite violating my own principles (and how I'd reject this change if
it came from you).
2020-04-13 15:57:05 +02:00
wm4 a8b84c9a1a zimg: add support for big endian input and output
One of the extremely annoying dumb things in ffmpeg is that most pixel
formats are available as little endian and big endian variants. (The
sane way would be having native endian formats only.) Usually, most of
the real codecs use native formats only, while non-native formats are
used by fringe raw codecs only. But the PNG encoders and decoders
unfortunately use big endian formats, and since PNG it such a popular
format, this causes problems for us. In particular, the current zimg
wrapper will refuse to work (and mpv will fall back to sws) when writing
non-8 bit PNGs.

So add non-native endian support to zimg. This is done in a fairly
"generic" way (which means lots of potential for bugs). If input is a
"regular" format (and just byte-swapped), the rest happens
automatically, which happens to cover all interesting formats.

Some things could be more efficient; for example, unpacking is done on
the data before it's passed to the unpacker. You could make endian
swapping part of the actual unpacking process, which might be slightly
faster. You could avoid copying twice in some cases (such as when
there's no actual repacker, or if alignment needs to be corrected). But
I don't really care. It's reasonably fast for the normal case.

Not entirely sure whether this is correct. Some (but not many) formats
are covered by the tests, some I tested manually. Some I can't even
test, because libswscale doesn't support them (like nv20*).
2020-04-13 15:56:27 +02:00
wm4 a8f4ca587d test: update img_formats.txt
This explicitly depends on the pixfmt list from FFmpeg (done so to
easily spot regression, incompatible changes, and other unexpected
things).

Some local changes in mpv change some of the output. For pal8 an alias
was added back, and the [GENERIC] markers are removed because the mpv
aliases are not dependent on the mpv config anymore (which was
unnecessary).

The other changes are due to ffmpeg adding some new formats.
2020-02-29 01:23:20 +01:00
wm4 a841fe9484 img_format: add gray/alpha planar formats
The zimg wrapper "needs" these formats as intermediary when repacking
the normal gray/alpha packed format. The packed format is used by the
png decoder and encoder, and is thus interesting.

Unfortunately, mpv-only formats are a mess right now, because all the
existing code is focused around using the FFmpeg metadata for pixel
formats. This should be improved, but not now, so make the mess worse.

This commit doesn't add support for it to the zimg wrapper yet.
2020-02-10 17:38:54 +01:00
wm4 cca02e51ef zimg: add alpha support
libzimg recently added direct alpha support and new API for it. (The API
change is rather minimal, and it turns out we can easily support old and
new zimg versions.)

This does not support _all_ alpha formats. For example, gray + alpha is
not supported yet, because my stupid design in the zimg wrapper would
require a planar gray + alpha format, while ffmpeg provides only a
packed one.
2020-02-09 19:16:54 +01:00
wm4 1dc3507474 path: add mp_path_is_absolute()
Just move it from mp_path_join_bstr() to this new function.
2020-02-06 14:14:35 +01:00
wm4 31acec5438 path: change win32 semantics for joining drive-relative paths
win32 is a cursed abomination which has "drive letters" at the root of
the filesystem namespace for no reason. This requires special handling
beyond tolerating the idiotic "\" path separator.

Even more cursed is the fact that a path starting with a drive letter
can be a relative path. For example, "c:billsucks" is actually a
relative path to the current working directory of the C drive. So for
example if the current working directory is "c:/windowsphone", then
"c:billsucks" would reference "c:/windowsphone/billsucks".

You should realize that win32 is a ridiculous satanic trash fire by the
point you realize that win32 has at least 26 current working
directories, one for each drive letter.

Anyway, the actual problem is that mpv's mp_path_join() function would
return a relative path if an absolute relative path is joined with a
drive-relative path. This should never happen; I bet it breaks a lot of
assumptions (maybe even some security or safety relevant ones, but
probably not).

Since relative drive paths are such a fucked up shit idea, don't try to
support them "properly", and just solve the problem at hand. The
solution produces a path that should be invalid on win32.

Joining two relative paths still behaves the same; this is probably OK
(maybe).

The change isn't very minimal due to me rewriting parts of it without
strict need, but I don't care.

Note that the Python os.path.join() function (after which the mpv
function was apparently modeled) has the same problem.
2020-02-06 14:10:40 +01:00
wm4 1293c40623 test: add some path handling tests
Exhaustive tests would be nice, but I'm only adding a test for a
function I'm going to change.
2020-02-06 13:50:41 +01:00
wm4 94d853d3a3 test: add tests for zimg RGB repacking
This tests the RGB repacker code in zimg, which deserves to be tested
because it's tricky and there will be more formats.

scale_test.c contains some code that can be used to test any scaler. Or
at least that would be great; currently it can only test repacking of
some byte-aligned-component RGB formats. It should be called
repack_test.c, but I'm too lazy to change the filename now.

The idea is that libswscale is used to cross-check the conversions
performed by the zimg wrapper. This is why it's "OK" that scale_test.c
does libswscale calls.

scale_sws.c is the equivalent to scale_zimg.c, and is of course
worthless (because it tests libswscale by comparing the results with
libswscale), but still might help with finding bugs in scale_test.c.

This borrows a sorted list of image formats from test/img_format.c, for
the same reason that file sorts them.

There's a slight possibility that this can be used to test vo_gpu.c too
some times in the future.
2019-11-09 01:55:13 +01:00
wm4 27d88e4a9b test: fix --unittest matching
Hurrr.
2019-11-08 21:22:49 +01:00
wm4 1edb3d061b test: add dumping of img_format metadata
This is fragile enough that it warrants getting "monitored".

This takes the commented test program code from img_format.c, makes it
output to a text file, and then compares it to a "ref" file stored in
git.

Originally, I wanted to do the comparison etc. in a shell or Python
script. But why not do it in C. So mpv calls /usr/bin/diff as a
sub-process now.

This test will start producing different output if FFmpeg adds new pixel
formats or pixel format flags, or if mpv adds new IMGFMT (either aliases
to FFmpeg formats or own formats). That is unavoidable, and requires
manual inspection of the results, and then updating the ref file.

The changes in the non-test code are to guarantee that the format ID
conversion functions only translate between valid IDs.
2019-11-08 21:22:49 +01:00
wm4 a6c8b4efa5 test: merge test_helpers.c and index.c
No need to keep them separate. Originally I thought index.c was only
going to contain the list of tests, but that didn't happen.
2019-11-08 20:34:07 +01:00
wm4 3e401bf652 test: make build fail if NDEBUG is defined
Defining NDEBUG via CFLAGS is the canonical way to disable assertions in
C. mpv respects this (and ta.c actually disables some debugging
machinery if it's defined).

But for tests, this is not useful at all. So if --enable-tests is passed
to configure, the user must not define NDEBUG, even if the rest of the
player does not care.

(We could just #undef NDEBUG, but let's not. Tests calling into the rest
of the player might depend on asserts there, or so.)
2019-11-08 14:23:56 +01:00
wm4 3ed9c1c970 test: just always provide a context for all entrypoints 2019-11-08 14:21:40 +01:00
wm4 fb56896319 test: make tests part of the mpv binary
Until now, each .c file in test/ was built as separate, self-contained
binary. Each binary could be run to execute the tests it contained.

Change this and make them part of the normal mpv binary. Now the tests
have to be invoked via the --unittest option. Do this for two reasons:

- Tests now run within a "properly" initialized mpv instance, so all
  services are available.
- Possibly simplifying the situation for future build systems.

The first point is the main motivation. The mpv code is entangled with
mp_log and the option system. It feels like a bad idea to duplicate some
of the initialization of this just so you can call code using them.

I'm also getting rid of cmocka. There wouldn't be any problem to keep it
(it's a perfectly sane set of helpers), but NIH calls. I would have had
to aggregate all tests into a CMUnitTest list, and I don't see how I'd
get different types of entry points easily. Probably easily solvable,
but since we made only pretty basic use of this library, NIH-ing this is
actually easier (I needed a list of tests with custom metadata anyway,
so all what was left was reimplement the assert_* helpers).

Unit tests now don't output anything, and if they fail, they'll simply
crash and leave a message that typically requires inspecting the test
code to figure out what went wrong (and probably editing the test code
to get more information). I even merged the various test functions into
single ones. Sucks, but here you go.

chmap_sel.c is merged into chmap.c, because I didn't see the point of
this being separate. json.c drops the print_message() to go along with
the new silent-by-default idea, also there's a memory leak fix unrelated
to the rest of this commit.

The new code is enabled with --enable-tests (--enable-test goes away).
Due to waf's option parser, --enable-test still works, because it's a
unique prefix to --enable-tests.
2019-11-08 00:26:37 +01:00
Stefano Pigozzi 899e0bd16b input: add gamepad support through SDL2
The code is very basic:

- only handles gamepads, could be extended for generic joysticks in the
  future.
- only has button mappings for controllers natively supported by SDL2.
  I heard more can be added through env vars, there's also ways to load
  mappings from text files, but I'd rather not go there yet. Common ones
  like Dualshock are supported natively.
- analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an
  activation threshold.
- only supports one gamepad at a time. the feature is intented to use
  gamepads as evolved remote controls, not play multiplayer games in mpv :)
2019-10-23 09:40:30 +02:00
Stefano Pigozzi cb32ad68f3 command: add sub-start & sub-end properties
These properties contain the current subtitle's start and end times.
Can be useful to cut sample audio through the scripting interface.
2019-09-22 09:19:45 +02:00
wm4 0b127312be test/linked_list: silence nonsense warnings
../misc/linked_list.h:71:34: warning: the address of ‘e6’ will always
evaluate as ‘true’ [-Waddress]

No shit, e6 is on the stack. But the macro argument is also allowed to
be NULL. Add some dumb nonsense to shut up the useless warning. (It's
probably useful in other contexts though, so don't disable it
completely.)
2019-09-21 22:30:38 +02:00
wm4 293dfc7825 test: fix cmocka assert_float_equal shadowing warnings
Just use cmocka's function. It takes an epsilon argument, which we now
provide directly.

There's no assert_double_equal() in cmocka (and the float variant
actually forces a conversion to the float type), but fortunately we
didn't use it.
2019-09-21 22:11:52 +02:00
wm4 782e428284 misc: add linked list helpers
This provides macros for managing intrusive doubly linked lists.

There are many ways how to do those in a "generic" way in C. For example
Solaris style lists are pretty nice:

https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/list.h
https://github.com/illumos/illumos-gate/blob/master/usr/src/common/list/list.c

I even have an independent implementation of this, which could be ISC
licensed. But I think it's easier to vomit ~100 lines of preprocessor
garbage, which has a lower footprint, and I think it wins slightly on
the side of type safety, simplicity, and ease of use, even if it doesn't
look as magically nice.
2018-05-24 19:56:35 +02:00
wm4 d36b85cfdf json: add some non-standard extensions
Also clarify this and previously existing differences to standard JSON
in ipc.rst.
2018-05-24 19:56:34 +02:00
wm4 76bff1a000 json: format slightly nicer escape sequences
Make use the escape sequences allowed by JSON.

Also update the linked RFC to the newest one.
2018-05-24 19:56:34 +02:00
wm4 711858377c test: add tests for json parser/formatter
This should have been done sooner.
2018-05-24 19:56:34 +02:00