cee-studio / cee-utils Goto Github PK

We can use AES to do encryption.

https://github.com/kokke/tiny-AES-c.git

cover_image?	string	id of the embed's image asset
description	string	application's description
icon	?string	id of the application's icon

This example shows the complexity of discord json data.

cover_image is optional
icon's value is nullable.

I propose we use suffix _opt for all optional field/keys.

struct { 
char * cover_image_opt;

char ** E; // used to check for the existence of a field
}

json_scanf(..,  "[cover_image]%s?    %E",   &p->cover_image_opt,  &p->E);  // %E is mandatory for all structs that have optional fields. 

Anyone who uses this field is supposed to call IS_DEFINED(p, cover_image_opt) to detect if it is present.

==28482== Invalid free() / delete / delete[] / realloc()
==28482==    at 0x483CA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==28482==    by 0x10B01E: ja_str_free (json-actor-boxed.c:37)
==28482==    by 0x115AC4: ntl_free (ntl.c:129)
==28482==    by 0x10B17E: ja_str_list_free (json-actor-boxed.c:64)
==28482==    by 0x10AD2D: load_search_params (test-reddit-api.c:53)
==28482==    by 0x10AE1B: main (test-reddit-api.c:73)
==28482==  Address 0x6a36158 is 24 bytes inside a block of size 40 alloc'd
==28482==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==28482==    by 0x1157BD: ntl_malloc_init (ntl.c:27)
==28482==    by 0x1158BB: ntl_calloc_init (ntl.c:65)
==28482==    by 0x11625D: ntl_from_buf (ntl.c:342)
==28482==    by 0x11566D: orka_str_to_ntl (orka-utils.c:248)
==28482==    by 0x10B21A: ja_str_list_from_json (json-actor-boxed.c:78)
==28482==    by 0x112C5E: apply_extraction (json-actor.c:2182)
==28482==    by 0x112D13: extract_value (json-actor.c:2207)
==28482==    by 0x11312F: extract_access_path (json-actor.c:2280)
==28482==    by 0x113355: extract_object_value (json-actor.c:2319)
==28482==    by 0x113B97: json_vextract (json-actor.c:2453)
==28482==    by 0x113D6F: json_extract (json-actor.c:2474)

To replicate issue remove comment block from test-reddit-api.c:53

This repo contains code that can be shared. So API documentation makes more sense.

https://medium.com/@naveen.maltesh/generating-code-coverage-report-using-gnu-gcov-lcov-ee54a4de3f11

This means the decimal point may be a , instead of a .. This makes strtod() less than optimal for parsing web-based responses, where the values may be received with no regard to the user's locale.

Title says it all, with this we can forbid usage of some commonly misused functions.
https://github.com/git/git/blob/master/banned.h

To reduce the complexity of the current code, and make it more reliable.

When parsing JSON, it is possible for a dictionary for example to be provided, or be NULL. It might be useful to have the option to detect NULL fields, and decide not to parse them if they are NULL. See example JSON below.

{"id":50919991711,"serialNumber":null,"owner":{"id":1344078314,"type":"User"},"created":"2019-12-03T02:49:36.457Z","updated":"2019-12-03T02:49:36.457Z"}

{"id":50920076429,"serialNumber":null,"owner":{"id":1344182127,"type":"User"},"created":"2019-12-03T02:52:36.14Z","updated":"2019-12-03T02:52:36.14Z"}

{"id":51542420781,"serialNumber":null,"owner":null,"created":"2019-12-14T17:20:50.357Z","updated":"2019-12-14T17:20:50.357Z"}

As shown, the first two have their owner fields filled in with information, but the other has it set to NULL. The behavior I am thinking of is similar to using the strstr function to detect if the key is NULL, but rather, built into the JSON parser as a feature.

This repo contains the most generic code, we should write test to test all important functions.

For example, file field here shouldn't be included in the JSON encoding/decoding functions:

    {
      "title":"Create Guild Sticker",
      "namespace":["create_guild_sticker"],
      "struct":"params",
      "fields":
      [
        {"name":"name", "type":{"base":"char", "dec":"*"}, "comment":"name of the sticker (2-30 characters)"},
        {"name":"description", "type":{"base":"char", "dec":"*"}, "comment":"description of the sticker (empty or 2-100 characters)"},
        {"name":"tags", "type":{"base":"char", "dec":"*"}, "comment":"autocomplete/suggestion tags for the sticker (max 200 characters)"},
        {"name":"file", "type":{ "base":"struct discord_file", "dec":"*" }, "loc":"multipart", "comment":"the sticker file to upload, must be a PNG, APNG, or Lottie JSON file, max 500 KB"}
      ]
    }

but it will be added nonetheless (and lead to a compilation error), unless its moved from the last position.

Currently, when running something similar to
json_inject(payload, sizeof(payload), "");
gives a runtime error of
./cee-utils/json-actor.c:1723: unexpected (null).

We might want this to give back an empty string or an empty array/object string.

We need more small tests

For sending a multipart/form-data content type we are required to send a body in the appropriate multipart format type (See here). Currently the temporary solution is to use curl_mime type, which can be used with some related functions for creating the multipart body. Unfortunately we can't access the multipart content itself and have to expose curl functions to the library developers. (See discord-public-channel.cpp:210 for example)

The inclusion of multipart_inject()/mime_inject() could provide a way to create multipart type body which can then be easily accessed via struct sized_buffer req_body

We will wrap more REST APIs' endpoints with our json deserialization methods. Implementing such a wrapper is one easy way to get a new contributor to start the contribution. The task is simple enough and there are endless APIs to wrap. We need to make the testing of this work easier for new contributors.

In this example, guild_template.is_dirty is a bool value that may receive a null value instead of either true or false:

1. How does json_extract() deal with dynamically typed JSON? For example:

var foo=0;
json_extract(payload, sizeof(payload), "(var):d", &foo);

Here foo expects that the type of var is of a integer. What is going to happen if, for example, var ends up being a string? Will the program crash, or will the assignment be ignored and move on? If the program crashes, I think a more desirable behavior would be to compare the jsmn type with the specifier provided. In this example we have a d specifier which corresponds to a int type, so the comparison would end up being:

// don't crash, but ignore
if (jsmn_tok->type == JSMN_PRIMITIVE && a->_.builtin == B_INT) {
  ...
}

Crashing is not ideal when dealing with APIs that don't "respect" their docs specifications. Any non-conforming JSON is enough to crash the program.