Removing longs from IntegerTopics in NetworkTables

[Turbojax07]

Recently, I have been working on my own NT logger, so I have been getting into logging ints, floats, and doubles.

When using the IntegerArraySubscriber class, I noticed that it didn't actually take int[], but instead the parameter was a long[]. This is the same case with IntegerSubscriber and their Publisher counterparts. Looking into this a bit more, I found that there wasn't a LongSubscriber, only the IntegerSubscriber. After asking around in the FIRST CHS discord, I learned that internally, NetworkTables logs ints with the int64_t type, which is a long in java. The problem I have with this argument is that a FloatTopic exists, which is a 32-bit decimal value. If there is support for logging 32-bit decimal values, then why is there no support for 32-bit integer values?

[Turbojax07]

After getting a few more responses in Discord, I have been made aware that message packing automatically reduces integer values to the minimum size, so the longest size is processed in code. The reason floats and doubles don't do this is because the process is more expensive than just sending the raw float/double value. Still wondering if this would be a good thing to add for semantics.

[PeterJohnson]

I think I'd be okay (for 2027) adding more variants at the API level, although all will still map to the same underlying integer type. The key issue to think through is what to do about numeric overflows--e.g. what do you get if someone publishes a large 64-bit number (that doesn't fit into 32 bits) and the subscriber is only a 32-bit integer? The fastest thing to do is truncate (otherwise we'll always have to check for every number if it overflows and saturate appropriately), but that's also probably the least correct answer?

[Turbojax07]

So the thing that you're worried about is if someone uses the NT API incorrectly and makes an IntegerSubscriber for a LongPublisher or vice versa?

[PeterJohnson]

It's not really using the API incorrectly, it's that we don't differentiate at a lower level between different sized integers, so integers on the wire may be as large as 64 bits.

[Turbojax07]

If it is too much of a concern, it wouldn't be too hard to implement some logic to prevent the wrapping that would occur with truncation.
Literally just:

// Inside IntegerEntryImpl.java
public int[] get() {
    long value = NetworkTablesJNI.getBooleanArray(m_handle, m_defaultValue);
    if (value > Integer.MAX_VALUE) return Integer.MAX_VALUE;
    if (value < Integer.MIN_VALUE) return Integer.MIN_VALUE;
    return value;
}

Something in the JNI/Native layer would be better though, this is just what I wrote up in a moment

[Turbojax07]

we don't differentiate at a lower level between different sized integers

I'm suggesting we start doing that.

[PeterJohnson]

There is no reason to do that. The protocol itself transparently handles integers up to 64-bit.