Thx David, I still prefer to have the assertion. Having assertions builtin is much better off to require tools for something this simple. Also, code should not be sloppy because one can use tools to detect ( I don't mean you, since the code is not originally written by you) Sun
On Tue, Nov 23, 2010 at 9:56 PM, David Coakley <dcoak...@gmail.com> wrote: > I only claimed to have fixed the buffer problems detected by FORTIFY_SOURCE. > > But I am willing to improve the code dealing with msg_str. Note that > the strings that are copied into msg_str are all constants and the > size is known at compile-time. Here is my proposed modification for > the first use of msg_str: > > OLD: > > msg_str[0] = NULL_CHAR; > strcpy(msg_str, vector_lvl_str[opt_flags.vector_lvl]); > strcpy(&msg_str[7], "\n"); > strcpy(&msg_str[8], task_lvl_str[opt_flags.task_lvl]); > > NEW: > > strncpy(msg_str, vector_lvl_str[opt_flags.vector_lvl], 7); > msg_str[7] = NEWLINE; > strncpy(&msg_str[8], task_lvl_str[opt_flags.task_lvl], 5); > msg_str[13] = NULL_CHAR; > > Optionally we could add a static assert that 13 < (sizeof(msg_str) / > sizeof(msg_str[0])), although the above is simple enough that the > FORTIFY_SOURCE checking will detect an overrun at compile-time. Thus > we can be sure that no overruns will happen at run-time for msg_str. > Is this satisfactory? > > On Mon, Nov 22, 2010 at 10:38 PM, Sun Chan <sun.c...@gmail.com> wrote: >> I don't see it that way, your fix just make the "buffer overflow" >> problem happen later in time, so it is not a fix that I consider sound >> Sun >> >> On Tue, Nov 23, 2010 at 11:15 AM, David Coakley <dcoak...@gmail.com> wrote: >>> Hi Sun, >>> >>> I think the changes that you are suggesting are an addition to the >>> changes in the submitted patch. If that is the case, then I would >>> rather make them as a separate commit as I have already tested the >>> patch and I know that it fixes the FORTIFY_SOURCE issue. >>> >>> On Mon, Nov 22, 2010 at 4:13 PM, Sun Chan <sun.c...@gmail.com> wrote: >>>> a most economic way to do that is to use #define like SZ_STR >>>> then afterwards, assert that strlen(msg_str) < SZ_STR >>>> Sun >>>> >>>> On Tue, Nov 23, 2010 at 8:11 AM, Sun Chan <sun.c...@gmail.com> wrote: >>>>> If we are fixing that, we might as well fix potential issues. E.g. >>>>> check for strlen and truncate, use alloca, ... or simply make it twice >>>>> the size (although it still technically is potentially wrong) >>>>> Sun >>>>> >>>>> On Tue, Nov 23, 2010 at 8:04 AM, David Coakley <dcoak...@gmail.com> wrote: >>>>>> Yes, I noticed that the msg_str buffer size seemed small. However, I >>>>>> didn't see any immediate problems and there were no more complaints >>>>>> from the FORTIFY_SOURCE checking so I left it as-is. >>>>>> >>>>>> On Mon, Nov 22, 2010 at 4:53 AM, Sun Chan <sun.c...@gmail.com> wrote: >>>>>>> your msg_str could get out of bound too (not now, but some fixes later >>>>>>> on). >>>>>>> Sun >>>>>>> >>>>>>> On Mon, Nov 22, 2010 at 3:31 PM, David Coakley <dcoak...@gmail.com> >>>>>>> wrote: >>>>>>>> Recently I tried to build Open64 with gcc-4.5.1 and FORTIFY_SOURCE >>>>>>>> checking turned on. The Fortran frontend would not run at all because >>>>>>>> of a failing buffer overflow check that occurred during command-line >>>>>>>> processing. Although this failure turned out to be a false alarm, it >>>>>>>> was fairly easy to work around. And since the FORTIFY_SOURCE checking >>>>>>>> did uncover some real problems, I thought it was worth making source >>>>>>>> changes to work around the problem rather than turning the checking >>>>>>>> off. >>>>>>>> >>>>>>>> The attached file msg.txt details the changes. >>>>>>>> >>>>>>>> Could a gatekeeper please review the patch? Thanks, >>>>>>>> >>>>>>>> -David Coakley / AMD Open Source Compiler Engineering >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Beautiful is writing same markup. Internet Explorer 9 supports >>>>>>>> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. >>>>>>>> Spend less time writing and rewriting code and more time creating >>>>>>>> great >>>>>>>> experiences on the web. Be a part of the beta today >>>>>>>> http://p.sf.net/sfu/msIE9-sfdev2dev >>>>>>>> _______________________________________________ >>>>>>>> Open64-devel mailing list >>>>>>>> Open64-devel@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
