[Bug 750847] dashdemux: variables containing time information should be guint64 not gint64

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=750847

--- Comment #18 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #17)
> Did you mean you actually *want* leading whitespace to be allowed ? I've
> just seem comment 2 from 
> https://bugzilla.gnome.org/show_bug.cgi?id=752428, which hints at yes.
> 

I would like the parser to follow the standard exactly and complain about every
detected deviation, so that humans can spot the problems with the mpd files.
Unfortunately, the user of the parser is the client application and it cannot
change the xml published by a service provider, even if it knows the mpd is not
conform to the standard.
The general consensus here is to make the parser as permissive as possible (we
can stil warn about deviations, but try to work around them), so that gstreamer
doesn't refuse to play some files that other parsers (which are less
restrictive) might play.
So, if there are some spaces at the beginning of a string and we can skip them
and still play the file, why not do it?

> Also, sscanf doesn't care much about range, it happily parses and discards
> upper bits:
> 
> $ ./a.out "3333333333"
> ret 1, value 3333333333
> $ ./a.out "33333333333"
> ret 1, value 3268562261
> $ ./a.out "333333333333"
> ret 1, value 2620851541
> $ ./a.out "3333333333333"
> ret 1, value 438711637
> $ ./a.out "33333333333333"
> ret 1, value 92149077
> 
> #include <stdio.h>
> 
> int main(int argc,char **argv)
> {
>   unsigned int u;
>   int ret=sscanf(argv[1], "%u", &u);
>   printf("ret %d, value %u\n", ret, u);
>   return 0;
> }
I know. Also, if you pass 33xx it will return 33 and not complain about the
extra data. We could (and I think we should) make the parser check also the
remaining of data from a string (parse the property completely) and issue a
warning to say something is wrong in the mpd file if extra data is detected.
Maybe discard the data and use the default values in such a case?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.