-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] How to read attributes of type
#4
Comments
Hi, as of now, the pattern field of
That would solve the problem, at least until better support for Also, be sure to create your libyang context with the |
We do not have problem to create a such patch (speaking about m_typeParsed) if necessary. But if you modify code out of Github (I do not know Gerrit), we would be more than happy to find such patch in upcoming week(s) :) Thanks for info, we already use |
I'm also struggling with this. Is there any way I could help to make this happen? |
Apologies for a late reply, real life happened.
I suppose this will also need exporting the
I thought that libyang tries to export all of the validation error which are found via Anyway, I understand that it's always nice to provide early, if possibly incomplete, validation directly on a frontend, so here's a patch, please report there (or here) whether it's enough for your use case: https://gerrit.cesnet.cz/c/CzechLight/libyang-cpp/+/5891 I have not tested how it plays with a chain of Also keep in mind that the YANG regular expressions have a well-defined semantics, and that e.g. the OpenConfig models use them in a non-YANG-compliant way (pattern anchored vs. non-anchored, but there's more unfortunately). Also, there's been some recent changes in libyang itself which fixed some Unicode-related bugs. |
It should be like you said and if some errors are missing, we would need the exact use-case and problem. You can create an issue in libyang with all this information. |
Yeah, you are right. Thank you for the patch. I will learn how to contribute to your repo on Gerrit and will create patches containing those changes in upcoming weeks.
We would open issue in libyang if problem lasts. |
Bug: #4 Change-Id: I20505d73d086cd50eee7e5307a3f6fab185ca35c
For future reference
You can then use |
There is ODR violation in libyang tests reported by ASan which breaks our CI builds. This commit temporarily (until this gets solved in upstream) pins the libyang version to 3.0.18 which builds just fine. The log from ASan: 52/60 Test #31: utest_plugins .....................***Failed 1.22 sec [==========] tests: Running 4 test(s). [ RUN ] test_add_invalid [ OK ] test_add_invalid [ RUN ] test_add_simple ================================================================= ==2826==ERROR: AddressSanitizer: odr-violation (0x7f6d170dcb40): [1] size=24 'ly_version_so' /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/ly_common.c:43 [2] size=24 'ly_version_so' /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/ly_common.c:43 These globals were registered at these points: [1]: #0 0x437ffa in __asan_register_globals (/home/ci/build/github/CESNET/libyang/tests/utest_plugins+0x437ffa) (BuildId: e79d14f37e59b6533b66d19363b25fea9e324edb) #1 0x7f6d16691b9e in asan.module_ctor ly_common.c #2 0x7f6d1aad7236 in call_init /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-init.c:74:3 #3 0x7f6d1aad7236 in call_init /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-init.c:26:1 #4 0x7f6d1aad732c in _dl_init /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-init.c:121:5 #5 0x7f6d1aad35c1 in _dl_catch_exception /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:211:7 #6 0x7f6d1aaddeeb in dl_open_worker /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-open.c:827:5 #7 0x7f6d1aad3522 in _dl_catch_exception /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:237:8 #8 0x7f6d1aade2e3 in _dl_open /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-open.c:903:17 #9 0x7f6d1a7b5713 in dlopen_doit /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlopen.c:56:15 #10 0x7f6d1aad3522 in _dl_catch_exception /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:237:8 #11 0x7f6d1aad3678 in _dl_catch_error /usr/src/debug/glibc-2.37-18.fc38.x86_64/elf/dl-catch.c:256:19 #12 0x7f6d1a7b51f2 in _dlerror_run /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlerror.c:138:17 #13 0x7f6d1a7b57ce /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlopen.c:71:10 #14 0x7f6d1a7b57ce in dlopen@@GLIBC_2.34 /usr/src/debug/glibc-2.37-18.fc38.x86_64/dlfcn/dlopen.c:81:12 #15 0x485f82 in dlopen (/home/ci/build/github/CESNET/libyang/tests/utest_plugins+0x485f82) (BuildId: e79d14f37e59b6533b66d19363b25fea9e324edb) #16 0xcb5ee3 in plugins_load_module /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/plugins.c:378:17 #17 0xcb5e67 in lyplg_add /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/src/plugins.c:589:11 #18 0xea2a60 in test_add_simple /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/tests/utests/basic/test_plugins.c:50:5 #19 0x7f6d1aac218f (/lib64/libcmocka.so.0+0x618f) (BuildId: 785844a0941c0bde763740a981d056f60aa9c7b7) #20 0x7f6d1aac2904 in _cmocka_run_group_tests (/lib64/libcmocka.so.0+0x6904) (BuildId: 785844a0941c0bde763740a981d056f60aa9c7b7) #21 0xea21a2 in main /home/ci/src/cesnet-gerrit-public/github/CESNET/libyang/tests/utests/basic/test_plugins.c:152:12 Change-Id: Id8a4771296d2e85de2ec29fbd17046d280d2eda2
Hi,
I would like to ask you whether it is possible to read attributes of the
type
. For example, we would like to accesspattern
of thestring
type, but I haven't found a way how to do it.Reason is that we use libyang compiled to WebAssemble, we transform YANG schema to JSON representation of YANG schema and we would like to validate simple validations like
pattern
,min
,max
on frontend while YANG always returns only 1 error during the validation phase.Code snippet
I have following code (simplified):
Default type
Custom type
Any hint or it is not supported yet? I have elementary level of C++ (and C), but it might be enough to publish
m_type
/m_typeParsed
using some getter so we can at least make workaround on C level if it is not supported.Thank you for your help and contribution to open source!
The text was updated successfully, but these errors were encountered: