Re: Compiler warning question

["Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>]

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