Upgrading to FreeRADIUS-3.x

[Nathan Ward]

> On 29/12/2017, at 9:58 PM, kiran kumar <kirankumar9856 at 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