[Insight-developers] snprintf portability (was: Fix possibility of buffer overflow in itkNumericSeriesF...)

[Williams, Norman K]

Of course we could use itksys::SystemTools::EstimateFormatLength, but
looking at THAT function, it seems like it isn't actually that robust.

I'm, at this point, confused about what the solution should be. Short of
parsing the format string directly it seems like we're going to settle on
a 'good enough' solution, and depend on ITK users not to try buffer
overrun exploits when they're reading in an image series.

On 1/19/11 10:01 AM, "Brad King" <brad.king at kitware.com> wrote:

>On 01/19/2011 10:49 AM, Code Review wrote
>> From Bill Lorensen <bill.lorensen at gmail.com>:
>> I think a better job could be done for windows. Currently, the first
>>snprintf
>> will always return -1 for windows.  If char c[10000]; was used instead
>>of char c;
>> most of the time (except for huge filenames) snprintf will return a
>>valid value
>> on all platforms.
>> To view, visit http://review.source.kitware.com/521
>
>In that case we might as well just use that result directly and only
>fall back to dynamic allocation when the stack buffer isn't big enough.
>
>For reference, I just experimented with snprintf and _snprintf on a
>bunch of compilers:
>
>  - HP
>  - SunPro
>  - SGI MipsPro
>  - IBM XL
>  - GNU on Linux
>  - Intel on Linux
>  - Intel on Windows
>  - VS 6, 7, 7.1, 8, 9, 10
>  - Borland 5.5, 5.6, 5.8
>  - Watcom
>  - GNU on Windows (MinGW)
>  - GNU on Cygwin (default, -mwin32, -c99, -mwin32 -c99)
>
>The attached snprintf.c shows the results I encountered.  The most
>interesting was on SGI where -D_XOPEN_SOURCE=500 changes the result.
>Only cases in which the buffer is large enough are consistent everywhere.
>
>-Brad