Open elfring opened 1 year ago
@elfring Thanks for noting this, though I'm not sure what your suggestion is here. According to my interpretation, the only danger could be that the header names used might become the name of a standard header at some point. However, since they are prefixed with NNEF, I am pretty sure that will not happen. Or is it something else?
:thought_balloon: How do you think about to avoid that this software depends on undefined behaviour?
Sure, I get that it may be the case, but as I see that only kicks in if a standard header/macro is named the same way, right? And I believe that it has extremely low chance (given that NNEF is a trademarked name), which would make this issue extremely low priority for us. Or do you see it otherwise? Please explain the situation that could possibly go wrong!
:thought_balloon: I would appreciate if you would care more for standard compliance also according to affected implementation details.
I would have appreciated if you explained the problem as I asked for. I do care for compliance, but I have other priorities to work on. In lack of further explanation, I assume this can be problematic with extremely low chance, so I'll handle this with low priority.
… if you explained the problem as I asked for.
:thought_balloon: This software tampers still with the reserved name space, doesn't it?
…, so I'll handle this with low priority.
:crystal_ball: Should you adhere to secure programming guidelines better?
I would like to point out that identifiers like “
_CNNEF_H_
” and “_NNEF_FRAGMENT_H_
” do not fit to the expected naming convention of the C++ language standard. Would you like to adjust your selection for unique names?