EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Compiler warning question
From: "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>
To: "Rivers, Mark L." <rivers at cars.uchicago.edu>
Cc: EPICS core-talk <core-talk at aps.anl.gov>, Michael Davidsaver <mdavidsaver at gmail.com>
Date: Thu, 17 Sep 2020 04:48:57 +0000
Hi Mark,

Actually you are passing a pointer to a 26-char array, so the compiler is warning you that what you’re doing isn’t strictly legal. I briefly looked at this code and these warnings on RHEL-8 a few weeks ago. The setEnums() routine takes a char *outStrings pointer that you point to one field in a struct (record), and you made the code inside setEnums() rely on the fact that this field is immediately followed by another identical field (for a binary record) or 15 more of them (multi-bit binary):

    char                znam[26];   /* Zero Name */
    char                onam[26];   /* One Name */

or

    char                zrst[26];   /* Zero String */
    char                onst[26];   /* One String */
    char                twst[26];   /* Two String */
    char                thst[26];   /* Three String */
    char                frst[26];   /* Four String */
    char                fvst[26];   /* Five String */
    char                sxst[26];   /* Six String */
    char                svst[26];   /* Seven String */
    char                eist[26];   /* Eight String */
    char                nist[26];   /* Nine String */
    char                test[26];   /* Ten String */
    char                elst[26];   /* Eleven String */
    char                tvst[26];   /* Twelve String */
    char                ttst[26];   /* Thirteen String */
    char                ftst[26];   /* Fourteen String */
    char                ffst[26];   /* Fifteen String */

The modern C standard says that you aren’t supposed to access data beyond the end of the object that you pointed to, even if you know how the compiler laid out the parent structure in memory. Sometimes I want to go back to writing BCPL or Forth…

It is possible to change the first argument to setEnums() to be something like a char (*names)[16][26] where the first dimension is the field index, but unless setEnums() gets moved into a different .c file and compiled separately from the routines that call it the compiler still knows that you’re passing it a pointer derived from znam but accessing onam through it:

In function ‘setEnums.constprop’,
    inlined from ‘interruptCallbackEnumBi’ at ../../asyn/devEpics/devAsynInt32.c:760:5:
../../asyn/devEpics/devAsynInt32.c:445:25: warning: strncpy’ forming offset [27, 51] is out of the bounds [0, 26] [-Warray-bounds]
         if (outStrings) strncpy((*outStrings)[i], inStrings[i], MAX_ENUM_STRING_SIZE-1);
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘setEnums.constprop’,
    inlined from ‘interruptCallbackEnumBo’ at ../../asyn/devEpics/devAsynInt32.c:774:5:
../../asyn/devEpics/devAsynInt32.c:445:25: warning: strncpy’ forming offset [27, 51] is out of the bounds [0, 26] [-Warray-bounds]
         if (outStrings) strncpy((*outStrings)[i], inStrings[i], MAX_ENUM_STRING_SIZE-1);
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don’t have a solution, but I’m attaching my patch that reduces the errors (slightly) to the above. I’m not convinced it’s correct.

- Andrew



On Sep 16, 2020, at 8:47 PM, Mark Rivers via Core-talk <core-talk at aps.anl.gov> wrote:

The warning is this:


[epics@viper asyn]$ make -s
In function ‘setEnums.constprop’,
   inlined from ‘interruptCallbackEnumBi’ at ../../asyn/devEpics/devAsynInt32.c:759:5:
../../asyn/devEpics/devAsynInt32.c:444:25: warning: ‘strncpy’ forming offset [27, 51] is out of the bounds [0, 26] [-Warray-bounds]
        if (outStrings) strncpy(&outStrings[i*MAX_ENUM_STRING_SIZE], inStrings[i], MAX_ENUM_STRING_SIZE-1);

So the compiler thinks I am passing an array of 26 byes, and so complains that I am writing to bytes 27 to 51. But actually I know that the array I am writing to is not really just 26 bytes long, it is actually larger. How do I communicate that knowledge to the compiler?

Mark

Sent from my iPhone

On Sep 16, 2020, at 8:37 PM, Chris Johns <chrisj at rtems.org> wrote:

On 17/9/20 11:28 am, Mark Rivers wrote:
That article is interesting but is about string truncation.  The warnings I am worried about are actually incorrectly flagging buffer overflow. I am hoping there is a cast or other method to avoid them.

OK, I am not across the full context. Reviewing the suggested patch the post
hinted that GCC looks for the terminating nul being written:

if (outStrings) {
strncpy(&outStrings[i*MAX_ENUM_STRING_SIZE], inStrings[i], MAX_ENUM_STRING_SIZE);
outStrings[i*MAX_ENUM_STRING_SIZE + MAX_ENUM_STRING_SIZE-1] = '\0';
}

New string functions in base don’t really help me since asyn needs to build, preferably without such warnings, on older versions of base.

That makes things harder.

Chris

-- 
Complexity comes for free, simplicity you have to work for.

Attachment: asyn-enum.patch
Description: asyn-enum.patch


References:
Compiler warning question Mark Rivers via Core-talk
Re: Compiler warning question Torsten Bögershausen via Core-talk
Re: Compiler warning question Ralph Lange via Core-talk
Re: Compiler warning question Michael Davidsaver via Core-talk
Re: Compiler warning question Chris Johns via Core-talk
Re: Compiler warning question Mark Rivers via Core-talk
Re: Compiler warning question Chris Johns via Core-talk
Re: Compiler warning question Mark Rivers via Core-talk

Navigate by Date:
Prev: [Bug 1895908] [NEW] epicsStackTraceTest fails on linux-aarch64 Andrew Johnson via Core-talk
Next: Re: Compiler warning question Benjamin Franksen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Compiler warning question Mark Rivers via Core-talk
Next: Re: Compiler warning question Benjamin Franksen via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 17 Sep 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·