pfSense

I'm also seeing this problem in the latest release.

2.3.2-RELEASE-p1 (i386)
built on Tue Sep 27 12:13:32 CDT 2016
FreeBSD 10.3-RELEASE-p9

These are both 32-bit installs (i386). So MAXINT will be int(2147483647) (2 gig). The numbers are returned by:
$rulescnt = pfSense_get_pf_rules();

Certainly $rulescnt array entries are going to wrap around at MAXINT. Maybe pfSense_get_pf_rules() on a 32-bit system will already have wrapped the number around anyway, even before trying to stuff them into PHP vars.

i386 is going away, but the SG-1000 is a 32-bit ARM device. I wonder if PHP on that hardware has the same MAXINT, or if does tricky enough stuff to keep track of overflow and effectively manage int up to 64-bit?

This isn't a PHP problem. pfSense_get_pf_rules() is a PHP function written in C as part of php56-pfSense-module. It can be seen at https://github.com/pfsense/FreeBSD-ports/blob/devel/devel/php56-pfSense-module/files/pfSense.c#L3012-L3050

I'm not much of a C hacker, but maybe it would help if those casts to long were unsigned, or cast to long long.

Yes, that is true. It depends on what "long" does in the environment in which the C is compiled. When compiled in the 64-bit image maybe it is a 64-bit integer, and maybe add_assoc_long() does the correct thing to transfer a 64-bit binary integer value into a PHP array value.

If it is made longlong in the C, then add_assoc_long() has to work with it (is there an add_assoc_longlong()?) and then what will happen on a 32-bit system that has C support for 64-bit integers (i.e. manipulating them as 2 pieces and sorting out the carries...) but the PHP on that 32-bit system still only supports 32-bit MAXINT. And the underlying pf needs to also use longlong underneath when accumulating the counter...

Can not duplicate this behavior in 2.4.0.b.20170401.1306, only positive numbers in the States column