|1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020||Index||1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020|
|<== Date ==>||<== Thread ==>|
|Subject:||Re: Unexpected change in behaviour of ai/ao device support|
|From:||"Johnson, Andrew N. via Tech-talk" <firstname.lastname@example.org>|
|To:||"email@example.com" <firstname.lastname@example.org>, "tech-talk (email@example.com)" <firstname.lastname@example.org>|
|Date:||Fri, 14 Jun 2019 21:58:02 +0000|
If you have problems following email quoting, the tech-talk archive seems to do a reasonable job with displaying most messages.
On 6/12/19 1:32 AM, email@example.com wrote:
Optimizing compilers nowadays are becoming much better at generating code that doesn't do what we think it should because our code happens to allow something that isn't strictly legal (but worked fine with a compiler from a few years ago). I'd rather be proactive in removing bad code while I'm actually working on it than have some compiler upgrade find it for us at a bad time.
I admit I did change the semantics, but not for the device support routines that I have access to because they all used positive or zero values for RVAL. The ai and ao records were designed to interface to individual ADCs and DACs, which almost invariably give/take either signed or offset zero integer values of various bit-widths. RVAL was designed to support the offset zero types, for which a zero analog value corresponds to a positive digital value (which is what you put into RVAL). That functionality still works perfectly with the new convert() code, and can now support the full 32-bit range that Dirk Zimoch was asking for at the time.
So rval = <int32_t> - <int32_t> which was fine as long as the subtraction didn't result in an overflow, since that would be UB.
Now let's look at the value 2147483392=0x7fffff00 instead; subtract -512=-0x200 from that and you get an int32_t overflow and hence UB.
That's not what gets put into RVAL, which is an int32_t so can't hold that anyway. The RVAL I actually get from the new code is -2147483648=0x80000000 because of the bounds checking, which was added to prevent signed overflows from taking place.
You weren't really supposed to put a negative number into ROFF (the Record Reference describes the field as "an offset to be subtracted from the adjusted value"). The fact that Hytec did that was unfortunately a latent bug in their code, which they aren't now around to fix.
So you're suggesting we break all the still-working drivers as well?
As you say it's possible for the device support to read the VAL field directly (or better the OVAL field, since you do want to support the ao's OROC functionality don't you?), although it would still have to implement LINR conversions and ASLO/AOFF adjustments itself.
-- Complexity comes for free, Simplicity you have to work for.