Simone Caronni created GUACAMOLE-720:
----------------------------------------

             Summary: Build failure with GCC 9
                 Key: GUACAMOLE-720
                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-720
             Project: Guacamole
          Issue Type: Bug
          Components: guacd
    Affects Versions: 1.0.0
            Reporter: Simone Caronni


In particular GCC 9 complains about this code:

{code}
> BUILDSTDERR: In file included from /usr/include/string.h:494,
> BUILDSTDERR:                  from /usr/include/winpr/collections.h:25,
> BUILDSTDERR:                  from /usr/include/freerdp/types.h:80,
> BUILDSTDERR:                  from /usr/include/freerdp/svc.h:24,
> BUILDSTDERR:                  from /usr/include/freerdp/utils/svc_plugin.h:27,
> BUILDSTDERR:                  from ./rdp_svc.h:25,
> BUILDSTDERR:                  from guac_svc/svc_service.h:24,
> BUILDSTDERR:                  from guac_svc/svc_service.c:22:
> BUILDSTDERR: In function 'strncpy',
> BUILDSTDERR:     inlined from 'VirtualChannelEntry' at 
> guac_svc/svc_service.c:56:5:
> BUILDSTDERR: /usr/include/bits/string_fortified.h:106:10: error: 
> '__builtin_strncpy' output may be truncated copying 7 bytes from a string of 
> length 7 [-Werror=stringop-truncation]
> BUILDSTDERR:   106 |   return __builtin___strncpy_chk (__dest, __src, __len, 
> __bos (__dest));
> BUILDSTDERR:       |          
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> BUILDSTDERR: cc1: all warnings being treated as errors
{code}

Which stems from this code:

{code}
>   /* Init channel def */
>     
>strncpy(svc_plugin->[plugin.channel_def.name|http://plugin.channel_def.name/], 
>svc->name,
>             GUAC_RDP_SVC_MAX_LENGTH);
{code}

The compiler is complaining because it can not prove the resulting string has a 
proper NUL terminator.  This can cause runtime faults and even  security issues.

Most folks are fixing this by either NUL terminating the string after the call 
to strncpy .  However, in some cases the string is not guaranteed to be NUL 
terminated -- in those cases the "nonstring" attribute is more appropriate.  
Note that using "nonstring" will cause the compiler to analyze use points and 
warn if you pass a "nonstring" variable to a routine that expects a properly 
terminated NUL string such as strlen.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to