Draft: json: create two static lib to serialize and deserialize input_item_t
This merge request is the first part of making the preparser running in a different process. Its purpose is to discuss and be sure that's the way to go.
This introduce de/serialization to and from json of the useful part input_item_t. The function's name and the two static lib structure are open to discussion and will perhaps be merge in one static library with all other de/serialization functions needed and not done yet.
Next step:
- preparser binary that receive preparse request and send responce.
- an API that spawn the preparser process and send preparse request.
Merge request reports
Activity
changed milestone to %4.0
- Resolved by Thomas Guillem
- Resolved by Gabriel Lafond-Thenaille
- Resolved by Gabriel Lafond-Thenaille
- Resolved by Gabriel Lafond-Thenaille
IMO there should only be one static library with both "to" and "from" functionality. And you don't need 2 folders for that: modules/misc/json should be enough.
- Resolved by Steve Lhomme
- Resolved by Gabriel Lafond-Thenaille
- Resolved by Gabriel Lafond-Thenaille
added 1 commit
- 368cc336 - misc: Create two static library to de/serialize input_item_t with json
- modules/misc/fromjson/fromjson.c 0 → 100644
68 * an integer. */ 69 static inline bool json_object_to_integer(const struct json_object *obj, 70 const char *name, int *number, 71 bool *error, int MIN, int MAX) 72 { 73 vlc_assert(obj != NULL); 74 vlc_assert(name != NULL); 75 vlc_assert(number != NULL); 76 vlc_assert(error != NULL); 77 78 double n = NAN; 79 json_object_to_number(obj, name, &n, error, MIN, MAX); 80 if (*error || isnan(n) || isinf(n) || (floor(n) != ceil(n))) { 81 *error = true; 82 return *error; 83 } Isn't
isinf
implied byisnan
?And then there are more straightforward means to check that a number is an integer, e.g.
modf(x, 1) == 0
orfloor(x) == x
. But I'm not sure why that should be an error in the first place. We don't want to trigger UB, but we don't care about losing precision (especially if it cannot happen from a non-broken sender).But I'm not sure why that should be an error in the first place.
I think it may signal information loss like that, that should be fair and may be convenient, but it should continue providing the number. I think it should be up to the caller whether to use the crooked integer.
I also think why there is such
json_object_to_integer()
besidesjson_object_to_double()
? Double to integer is a broader thing than serialization, so if there is such a need then it should probably be in the core so that it can be used anywhere.