olliv / data-record Goto Github PK

Support all the field types.

Possible cases:

• A pointer to an array of strings
• An array of pointers to strings
• A pointer to an array of string pointers
• An array of pointers to strings pointers
• An array of pointers to arrays of strings
• An array of pointers to arrays of strings pointers

Should it be configurable?

The deserializer can't properly parse most of the array types.

A type like int32_be[123] should define an array.

Currently it's fairly easy to read a struct with a pointer to union data. There are indeed multiple ways, either the struct might be declared with a union of pointers or the values can be casted or memcpy()d depending on the case.

However, to create such a union in the JS side is a bit harder. Currently it requires one type definition per type in the union. If the header generator is used this will result a number of structs. data-record will make sure the alignment is always correct so they C side can technically still just use one struct.

The biggest problem in implementing a union type is that the serializer would need extra info about which type to select. Using the write functions would work for non-pointers.

Currently serializing an array requires some string parsing that's know to be slow in V8. That part should be offloaded to the compiler.

It would be more efficient to unroll the serialization loop for small structs and generate JS code for serializing.

Copy data after the end of the struct and make a pointer to it in the struct.
This doesn't need to support growing the buffer at serialization time, it's enough if the alloc function can create a large enough buffer.

Currently there are no checks in JS nor C.

Currently even when align is set the nested records are not aligned properly.

• Change the default
• Fix tests and possibly add new test cases testing both align and no align

Implement C enum type.

https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes

Default values both ways.

The following functions don't currently handle arrays correctly:

readValue(compiledDef, buf, path)
readString(compiledDef, buf, path, encoding)
writeValue(compiledDef, buf, path, value)
writeString(compiledDef, buf, path, value, encoding)
createReader(compiledDef, buf, path)
createStringReader(compiledDef, buf, path)
createWriter(compiledDef, buf, path)

They should either support arrays directly or there should be array variants. Latter sounds better as it could possibly also support indexing too.

Generate C headers and inline functions for accessing the data.

Currently compile builds a sort of packed struct but it would be better to support normal structs for performance and ease of use.

Allow selecting between BE, LE, HOST, NET.

NET should always add hton() calls to the C header generator.

Add endianless-types that use either the selected endianness or the host endianness.

Line control could be possibly used to help with the error messages:

https://gcc.gnu.org/onlinedocs/cpp/Line-Control.html#Line-Control