[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaRocks query: LuaSec compiler warnings...
- From: Bruno Silvestre <bruno.silvestre@...>
- Date: Thu, 17 Oct 2019 11:43:09 -0300
This problem came from LuaSocket. Luarocks is installing it as dependency.
from LuaSocket 3.0-RC1, file src/option.c:40,41
char msg[45];
sprintf(msg, "unsupported option `%.35s'", name);
It was fixed in 'master' branch:
char msg[57];
sprintf(msg, "unsupported option `%.35s'", name);
regards
--
bruno
On Wed, Oct 16, 2019 at 12:42 AM sur-behoffski
<sur_behoffski@grouse.com.au> wrote:
>
> G'day,
>
> I'm not authorised to use a more direct path, so I'm trying the general lua-l
> list to raise an issue regarding compiler warnings in the rock luasec:
>
> I get a slew of warnings when installing luasec along the lines of:
>
> > src/options.c:41:43: warning: ‘%.35s’ directive writing up to 35 bytes into a region of size 25 [-Wformat-overflow=]
> > sprintf(msg, "unsupported option `%.35s'", name);
> > ^~~~~
> > In file included from /usr/include/stdio.h:862:0,
> > from /usr/include/lua5.1/lauxlib.h:13,
> > from src/options.c:7:
> > /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 22 and 57 bytes into a destination of size 45
> > return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > __bos (__s), __fmt, __va_arg_pack ());
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I don't know how potentially damaging these warnings are; I merely not that newer
> C compilers (here, gcc-7.4 under Linux Mint 19.1):
>
> gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
>
> gcc has, over the course of the last few releases (6.x up to the current 9.x)
> become better at code flow analysis, and, as a benefit, become more picky at
> identifying potential C coding mistakes, such as buffer overflow. (Misleading
> indentation, of the kind that caused the Apple "goto fail;" bug, is another
> one.)
>
> I'm reporting this diagnostic to this list, when I'm a bit of a "babe in arms"
> regarding bug reporting and tracking, and so:
>
> 1. If there is suitable project site, with an issue tracker, please "TELL ME
> WHERE TO GO"!.
>
> 2. In the absence of Item 1, could someone please address these compiler
> warnings? I'm striving to work in a world where I can wind up the compiler
> warnings to "-Wall -Wextra -Wpedantic" and still have zero warnings. This
> is inspired, in part, from my experience in working in a company that was
> striving (and succeeded) to produce an extremely-reliable product (the test
> team had tools to insert *every* possible error return into *every* actual
> system call, and these were all part of the regression test rig); a second
> reason is that I desire to have the extended Lua ecosystem that I use,
> including but not limited to LuaRocks, to be a +zero-warnings" system.
>
> I'm also inspired partially by Gerard Holzmann's "Mars Code" approach:
>
> https://www.usenix.org/conference/hotdep12/workshop-program/presentation/Holzmann
>
> in which his team managed to produce several million lines of code -- far
> too many to be reviewed manually -- and was successful in producing the
> software portion of a hardware/software/remote system that achieved a very
> complex goal.
>
> Coding standards, static and dynamic review tools, and continuous
> integration featured in his approach.
>
> My hope is to be a "devil's advocate" at times when I see code that falls
> below extremely high standards -- and standards that are being lifted in an
> incremental fashion as compiler technology improves. I do not claim to be
> a saint myself -- and so would only point out cases where fixed are close
> to trivial.
>
> So, feedback on this message, my experience with LuaSec, and any other
> issue raised by this message is welcome. I ultimately hope that the
> extended Lua community benefits from my actions; this is not something
> that I always achieve.
>
> cheers,
>
> sur-behoffski (Brenton Hoff)
> programmer, Grouse Software
>