- Sep 30, 2023
-
-
Jonathan Schöbel authored
Deregistering a global attribute normally is not possible, as basically every other tag has to be added. This was implemented now. Originally it was intended to provide the caller with the information, that a global attribute has to be converted into a local one before removal. However such internals should not be exposed to the caller. As it stands there is no real reason to inform a caller, whether an attribute is local or global. Also, there is a problem that the predicate is burdened with the possibility, that the attribute doesn't exists, thus it can't return a boolean directly. Both is why, the predicate isn't added yet. Also a bug was detected in the method remove_tag_for_all_attrs. It removes an attribute while also iterating over it, thus potentially skipping over some attribute and maybe also invoking undefined behaviour by deallocating space after the array.
-
Jonathan Schöbel authored
Global attributes are represented by empty attributes. A global attribute is an attribute, that is accepted for any tag. It is refused to remove a specific tag for a global attribute, as this would mean to "localize" the tag, thus making it not global anymore. The method to do that and a predicate for globalness is missing yet.
-
- Sep 29, 2023
-
-
Jonathan Schöbel authored
-
Jonathan Schöbel authored
Similar to the tags, the attributes can be initialized. Missing tags are automatically added. The declaration syntax is currently a bit annoying, as the tags, that belong to an attribute, either have to be declared explicitly or a pointer to the tag declaration must be given, but then only concurrent tags are possible. Support for global attributes is likewise missing; it must be ensured, that (tag_n != 0) && (tags != NULL). Otherwise validator will be inconsistent and there might be a bug.
-
- Sep 06, 2023
-
-
Jonathan Schöbel authored
Originally the ids were intended to be useful for linking different information together internally, and for providing references externally. However, they weren't used internally, for this, pointers seamed to be more useful, as they also allow to directly access the data and also have a relation defined. Regarding reference purposes, they aren't really needed, and it is more convenient to directly use some strings, and they aren't more performant, as there still have to be internal checks and looking for an int isn't more performant, then looking for a pointer. Also, they have to be stored, so they need more memory and also some code, to be handled.
-
Jonathan Schöbel authored
The Validator can check if a attribute is allowed in a tag. It does so by associating allowed tags with attributes. This is done in that way, to support also attributes which are allowed for every tag (global attributes), but this is not yet supported. So some functions allow for NULL to be passed and some will still crash. The predicate SH_Validator_check_attr returns whether an attribute is allowed for a specific tag. If tag is NULL, it returns whether an attr is allowed at all, not whether it is allowed for every tag. For this another predicate will be provided, when this is to be implemented. The method SH_Validator_register_attr registers an tag-attr combination. Note, that it will automatically call SH_Validator_register_tag, if the tag doesn't exist. Later it will be possible, to set tag to NULL to register a global attribute, but for now the method will crash. The method SH_Validator_deregister_attr removes a tag-attr combination registered earlier. Note, that deregistering a non existent combination will result in an error. This behaviour is arguable and might be subject to change. When setting only tag to NULL, all tags for this attribute are deregistered. When setting only attr to NULL, all attrs for this tag are deregistered. This might suffer from problems, if this involves some attrs, that are global. Also this will use the internal method remove_tag_for_all_attrs, which has the problem, that it might fail partially. Normally when failing all functions revert the program to the same state, as it was before the call. This function however is different, as if it fails there might be some combinations, that haven't been removed, but others are already. Nevertheless, the validator is still in a valid state, so it is possible to call this function a second time, but it is not sure, which combinations are already deregistered. As the attrs also use the internal strings of the tags, it must be ensured, when a tag is deregistered, that all remaining references are removed, otherwise there would be dangling pointers. Note, that for this also remove_tag_for_all_attrs is used, so the method SH_Validator_deregister_tag suffers from the same problems listed above. Also if this internal method fails, the tag won't be removed at all. Furthermore, the tests for deregistering a tag are still missing.
-
- Aug 16, 2023
-
-
Jonathan Schöbel authored
A attribute can be deregistered by calling SH_Validator_deregister_attr. Note that deregistering an attr, that was never registered is considered an error, but this may change, as technically it is not registered afterwards and sometimes (i.e. for a blacklist) it might be preferable to ensure, that a specific attr is not registered, but it is not clear whether there should be an error or not. Also the deallocating of the data used for an attr was moved to an extra method, as this is needed in several locations and it might be subject to change.
-
- Jul 27, 2023
-
-
Jonathan Schöbel authored
-