lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

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