unfortunately it does not work!
As you can see in the forum post, the wiki page states that the subnets from 0 to 7 are never used in practice. THe wiki table additionaly states the first subnet (class A) as a cidr format of /8.
according to the RFC 950 generally all subnets from /0 to /32 are possible.

Due development we already had this issue. I realised that all subnets from /1 to /7 or /8.0.0.0 to /254.0.0.0   are not correctly converted.
Cause for this must be the used function  &Net::IPv4Addr::ipv4_cidr2msk($cidr) which should convert the addresses. This function only operates as expected when the subnet is greater than /7.

If we want to allow these subnets, someone else should have look at the code of this module to fix the wrong conversions.

My approach though was to limit the subnet to /8 till /32 in general-functions.
You can test this by yourself.

Therefor please feel free to adapt the functions 

iporsubtocidr
iporsubtodec

and make a "0" at the points where now a "8" is located. YOu wills ee that the subnets are not correctly converted with the earlier mentioned module  &Net::IPv4Addr.

At this point i am not able to fix anything as long as these function is not fixed or an alternative is provided

Well, in that case, the module cannot be used. If an update does not fix the problem, then you can implement the method on your own. It is just a little bit of maths. I got one here in shell, which can be easily transferred to perl:

http://cgit.ipfire.org/network.git/tree/src/hooks/zones/bridge.configs/ipv4-static#n143

After testing around and reviewing i found another function which was involved in the process which still had the restriction to a /8 network.

I adapted the general-functions script and now it seems to work as expected.
Please test this commit:

http://git.ipfire.org/?p=people/amarx/ipfire-2.x.git;a=commit;h=968fcbfa86c77ae3cb7e64f2c28a82cc12d27b41