Add default value to fields

[dawoun]

Currently, the resulting structure is allocated by the library, which means there is no way to know if an optional fields was loaded from the yaml file or not, as the memory is always set to zero.

When an optional field is allocated, it could be instead set to a default value which will be supplied in the field's schema.

[tlsa]

Agreed, this would we useful. It's something I've thought of, but never implemented because I've not had a need for it so far.

I'll try to have a look into it soon.

[NitinSRKalavala]

Have you had a chance to look into this?

[tlsa]

I've had a think about it.

Basically, I'd add a void *def_val member to the struct cyaml_schema_value.

So the value schema could provide a pointer to a default value, or NULL if there is no special default value.

Since it's a pointer it would work for any enum cyaml_type.

Handling default types for "scalar" types, e.g. CYAML_INT, CYAML_BOOL, etc is reasonably straightforward. We'd just copy the value in.

It gets more complex with the default value for a more complex type, like CYAML_MAPPING. It would effectively have to deep clone any nested structures, arrays and values according to the mapping's schema. It's doable and I have some code for this, but it's not simple, and it's not been rebased recently. After the cloning, the rest of the code would have to be updated to e.g. free anything that came from a default that gets replaced by a given value.

The other issue is it requires an ABI change, so I'd have to make a libcyaml 2.0 release for this.

[dawoun]

The other issue is it requires an ABI change, so I'd have to make a libcyaml 2.0 release for this.

This, specifically, can be avoided by having specialized macros that take the new def_val pointer along with the existing schema macros, and having the old news just call the new ones with NULL as the default value. I believe that won't change the ABI (unless you mean the structures are a part of the ABI. That can also be handled by having new structures containing the old ones and having a extra field following the base, but that also means making a duplicate of all the functions using them and there lies dragons and the Windows API).

[tlsa]

This, specifically, can be avoided by having specialized macros that take the new def_val pointer along with the existing schema macros, and having the old news just call the new ones with NULL as the default value. I believe that won't change the ABI (unless you mean the structures are a part of the ABI.

Yep, changing the structures will change the ABI. The structures are used in a mapping fields schema array, so if the size of the structure changes, compiled client code would not be compatible with a libcyaml shared library before and after that change.

That can also be handled by having new structures containing the old ones and having a extra field following the base, but that also means making a duplicate of all the functions using them and there lies dragons and the Windows API).

Indeed, but I don't want to go there. I'd rather stock up a bunch of useful changes (e.g. support for unions, default values and numerical value ranges) and make a v2.0.0.

[acepaceNS]

e functions using them and there lies dragons and the Windows API).

Indeed, but I don't want to go there. I'd rather stock up a bunch of useful changes (e.g. support for unions, default values and numerical value ranges) and make a v2.0.0.

Is whats blocking you time?

[dawoun]

A possible solution that doesn't break any existing code or compiled binaries: https://github.com/tlsa/libcyaml/pull/185

[MasterMind2k]

Hi.

Without default values we are unable to have a simple migration process from old to new schema, because in old schema keys are missing.

Eagerly awaiting support for default values :).