Problem with ROFF change in ai/ao

I just found that this had been discussed in Tech Talk already:
https://epics.anl.gov/tech-talk/2019/msg00992.php

The original change (released 7½ years ago) was to properly support 32-bit raw values as you requested in https://epics.anl.gov/tech-talk/2013/msg00684.php but without triggering UB, which modern compiler optimizers love to rely on to break previously-working-but-non-portable code.

ROFF can't hold negative values, it was designed to support ADCs and DACs with an offset zero. If you have device support that was setting a negative ROFF it was depending on overflowing a uint32 calculation, which gcc allows with the -fwrapv flag but EPICS doesn't set that and it isn't portable.

I don't think we can change this in the record types at all, the device support has to provide any fixes necessary IMHO.

Hmm… We have a driver that sets ROFF to -512. I’ll need to see how I can modify it. My first attempt was to simply use EOFF instead (properly scaled of course) but that does not work with breakpoint tables. Another case was a user who had set ROFF to a negative value in his template or from another record or something like that (with another driver which does not use ROFF).
I guess we cannot have both, full 32 bit unsigned AND negative values unless ROFF was a double (or 64 bit signed int).