According to [1] EINTR is a possible errno for fsync(),
so handle it as all other EINTR (do/while(errno == EINTR)).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
strncpy() is assumed to be for strings so the compiler assumes that
it will need an extra byte for the string-terminaning NULL.
For cases where we know it's actually "binary" data, just copy it
with memcpy.
https://bugzilla.gnome.org/show_bug.cgi?id=795756
Implement GstDynamicTypeFactory as a new registry feature.
GstDynamicTypeFactory provides a way of registering a GType
into the registry, such that it will be registered as a dynamic
type when the registry is loaded, and then automatically loaded
if the type is needed during caps parsing.
This allows using non-core types in pad templates, by loading a
registry feature to create the GType on the fly.
https://bugzilla.gnome.org/show_bug.cgi?id=750079
lseek() returns the offset if successful, and this is != 0 and
does not indicate an error. And if it does actually fail, don't
return FALSE (0) as an int, but -1. None of these things are
likely to have made a difference, ever. I don't think the offset
seek can ever actually happen, the current file position and the
current offset should always be increased in lock step, unless
there was an error in which case we'd just error out.
There are many good use cases for GstIndex and we want
to add it back again in some form, but possibly not with
the current API, which is very powerful (maybe too powerful),
but also a bit confusing. At the very least we'd need to
make the API bindings-friendly.
The only reason these two functions are still around is that at some
point in the past they were in a public header, so we can't really
remove them now even though they should have been private all along
(and aren't really particularly useful). Since these are just empty
stubs now that do nothing but return FALSE and will be removed in
0.11 anyway, we may just as well deprecate them formally.
This makes the generated code faster since:
* It won't have to read an undirect value (which will most likely be
outside of the L1/L2 cache)
* We know that value never changes (the compiler has no clue that it doesn't).
When writing a cache chunk fails, we were freeing the node and jump to a final
cleanup which dereferenced a null pointer. Leve freeing the node to the cleanup
code in fail_free_list. (sorry for committing wrong fix before).
When writing a cache chunk fails, we were freeing the node and jump to a final
cleanup which dereferenced a null pointer. Leve freeing the node to the cleanup
code in fail_free_list.
The previous commit was bogus, as was the check before. We just point m to the file data,
so neither it nor its members will be NULL. Better check if we have enough data.
