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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>>>> 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
>>>>>>> [email protected]
>>>>>>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/open64-devel
