[asterisk-dev] [Code Review] 4530: clang compiler warning: -Wgnu-variable-sized-type-not-at-end

Diederik de Groot reviewboard at asterisk.org
Sun Mar 29 21:34:10 CDT 2015



> On March 30, 2015, 4:11 a.m., Matt Jordan wrote:
> > So, small problem with this change. When compiling with gcc 4.8.2, I get the following warning:
> > 
> > In function ‘read’,
> >     inlined from ‘inotify_daemon’ at stdtime/localtime.c:380:6:
> > /usr/include/x86_64-linux-gnu/bits/unistd.h:42:2: error: call to ‘__read_chk_warn’ declared with attribute warning: read called with bigger length than size of the destination buffer [-Werror]
> >   return __read_chk_warn (__fd, __buf, __nbytes, __bos0 (__buf));
> > 
> > 
> > Interestingly, the build agents didn't kick this back. But we'll need to find a way to get this fixed for gcc as well.
> 
> Matt Jordan wrote:
>     So, this is interesting. Looking at unistd.h:
>     
>     extern ssize_t __read_chk (int __fd, void *__buf, size_t __nbytes,
>                                size_t __buflen) __wur;
>     extern ssize_t __REDIRECT (__read_alias, (int __fd, void *__buf,
>                                               size_t __nbytes), read) __wur;
>     extern ssize_t __REDIRECT (__read_chk_warn,
>                                (int __fd, void *__buf, size_t __nbytes,
>                                 size_t __buflen), __read_chk)
>          __wur __warnattr ("read called with bigger length than size of "
>                            "the destination buffer");
>     
>     __fortify_function __wur ssize_t
>     read (int __fd, void *__buf, size_t __nbytes)
>     {
>       if (__bos0 (__buf) != (size_t) -1)
>         {
>           if (!__builtin_constant_p (__nbytes))
>             return __read_chk (__fd, __buf, __nbytes, __bos0 (__buf));
>     
>           if (__nbytes > __bos0 (__buf))
>             return __read_chk_warn (__fd, __buf, __nbytes, __bos0 (__buf));
>         }
>       return __read_alias (__fd, __buf, __nbytes);
>     }
>     
>     
>     That is, if __nbytes is greater than the result of GCC's built-in object size (https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html) for the struct, we'll kick back a warning.
>     
>     As it turns out, this is because there is an error in the code here - we're passing the address of the pointer to the struct, not iev, which is a pointer to the struct. Hence, the number of bytes is probably going to be lot larger than the number of bytes that make up a pointer! Changing this to just read from the pointer to the struct fixes the warning.

I guess i was running into the same problem whem running the tests/test_time.c using the clang compiled version. It segfaulted in inotify_daemon as wel. Thanks for finding/fixing this one. Really making progress here.


- Diederik


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4530/#review14961
-----------------------------------------------------------


On March 30, 2015, 3:52 a.m., Diederik de Groot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4530/
> -----------------------------------------------------------
> 
> (Updated March 30, 2015, 3:52 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24917
>     https://issues.asterisk.org/jira/browse/ASTERISK-24917
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> clang's static analyzer will throw quite a number warnings / errors during compilation, some of which can be very helpfull in finding corner-case bugs\nclang compiler warning:-Wgnu-variable-sized-type-not-at-end
> 
> 
> Diffs
> -----
> 
>   /branches/13/main/stdtime/localtime.c 433444 
> 
> Diff: https://reviewboard.asterisk.org/r/4530/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Diederik de Groot
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150330/b46b18bb/attachment-0001.html>


More information about the asterisk-dev mailing list