On 29/12/2017, at 9:58 PM, kiran kumar <kirankumar9856@gmail.com> wrote:
We would like to stick with C++ modules as these are custom modules created to meet the requirements and are verified. I have updated the module code as per standards of FR-v3.x and got stuck with below issues.
It is very difficult to claim that a module is verified if it is compiled against a new major version. I would say that the module is not verified anymore in that case. But, your arbitrary constraints are your own arbitrary constraints I guess… seems pretty silly, though.
In file included from /usr/include/freeradius/radiusd.h:28:0, from rlm_module.cpp:1: /usr/include/freeradius/libradius.h:190:25: error: '<anonymous>' declared as a 'virtual' field unsigned int virtual : 1; //!< for dynamic expansion ^
`virtual' is a reserved word in C++.
/usr/include/freeradius/libradius.h:612:64: error: expected ',' or '...' before 'new' VALUE_PAIR *fr_cursor_replace(vp_cursor_t *cursor, VALUE_PAIR *new); ^
`new’ is a reserved word in C++.
In file included from rlm_module.cpp:2:0: /usr/include/freeradius/modules.h:67:19: error: expected unqualified-id before 'typename' char const *typename; //!< Type name e.g. "Auth-Type". ^ /usr/include/freeradius/modules.h:67:18: error: expected ';' at end of member declaration char const *typename; //!< Type name e.g. "Auth-Type". ^ /usr/include/freeradius/modules.h:67:27: error: expected nested-name-specifier before ';' token char const *typename; //!< Type name e.g. "Auth-Type". ^
`typename' is a reserved word in C++.
looks like FR source code needs to be updated to make it compatible with C++ modules.
There would need to be a patch where `virtual’, `new’, and `typename` are replaced with something else. That wouldn’t be an unwieldy task. You should be able to submit that. I don’t know that it would be accepted though. You’d need to change these once you’d updated the attr_flags struct: src/lib/dict.c:1777: flags.virtual = 1; src/main/xlat.c:1844: if (!vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3083: if (attr->tmpl_da->flags.virtual) { src/main/modcall.c:3232: if ((vpt->type == TMPL_TYPE_ATTR) && vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3450: if ((vpt->type == TMPL_TYPE_ATTR) && vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3460: if ((vpt->type == TMPL_TYPE_ATTR) && vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3674: if ((g->vpt->type == TMPL_TYPE_ATTR) && g->vpt->tmpl_da->flags.virtual) { src/main/modcall.c:3820: if ((g->vpt->type == TMPL_TYPE_ATTR) && g->vpt->tmpl_da->flags.virtual) { You’d also need to change the fr_cursor_replace implementation and declaration to not refer to `new’. Here’s what you’d need to change after updating the section_type_value_t struct: src/main/modules.c:1012: RDEBUG2("%s sub-section not found. Ignoring.", section_type_value[comp].typename); src/main/modules.c:1074: section_type_value[comp].typename, name2); src/main/modules.c:1115: section_type_value[comp].typename); src/main/modules.c:1136: section_type_value[comp].typename) == 0) { src/main/modules.c:1756: section_type_value[comp].typename); src/main/modules.c:1798: cs2 = cf_section_sub_find_name2(subcs, section_type_value[comp].typename, cf_pair_attr(cp)); src/main/modules.c:1813: for (type_cs = cf_subsection_find_next(subcs, NULL, section_type_value[comp].typename); src/main/modules.c:1815: type_cs = cf_subsection_find_next(subcs, type_cs, section_type_value[comp].typename)) { src/main/modules.c:1823: cs2 = cf_section_sub_find_name2(subcs, section_type_value[comp].typename, cf_section_name2(type_cs)); Note though - I have only looked at the v3.0.x branch. I have not considered v4.0.x. It looks like the virtual flag is used in a few more places there, etc. Looks like typename is not used outside the section_type_value_t struct definition though, so perhaps you’re in luck. Not sure what *other* issues would come up if you were able to solve the above. -- Nathan Ward