building glaurung2.1 from empty code project

[Aleks Peshkov]

UCI and Winboard protocols are line buffered. I agree with Bob that disabling input buffering is a very ugly hack. Sending response to GUI char by char is even worse and huge waste of resources because only complete lines have sense and are expected by opposite side of protocol data-stream.

C-strings are root of evil. That is written in all decent C++ books and security guides. Microsoft compiler warnings about deprecating C-standard library is misleading. Using Microsoft-only "secure API" is an immediate source of non portable code.

[CThinker]

C-strings are root of evil. That is written in all decent C++ books and security guides. Microsoft compiler warnings about deprecating C-standard library is misleading. Using Microsoft-only "secure API" is an immediate source of non portable code.

Those secure replacements are not MS-only. They are part of the C standard.

Check out the section on "TR 24731-1: Extensions to the C Library Part I: Bounds-checking interfaces".

http://www.open-std.org/jtc1/sc22/wg14/ ... ects#24731

It just so happened that MS is quick at supporting those new functions.

[Dann Corbit]

UCI and Winboard protocols are line buffered. I agree with Bob that disabling input buffering is a very ugly hack. Sending response to GUI char by char is even worse and huge waste of resources because only complete lines have sense and are expected by opposite side of protocol data-stream.

C-strings are root of evil. That is written in all decent C++ books and security guides. Microsoft compiler warnings about deprecating C-standard library is misleading. Using Microsoft-only "secure API" is an immediate source of non portable code.

There are some horrible things still in the existing C standard.
gets() and scanf() with %s format specifier are basically unforgivable.

[Steelman]

It is not about the API being old or being from C. Note that even the replacement being suggested is classic C.

The issue here is security. Functions from the C library that have no buffer checking should be avoided, because an attacker could supply you with an input and when you process it, you overrun your buffers.

The classic example is strcpy(). This function does not know what the destination size is. So, even if the source is larger than the destination, it would happily copy everything over.

The preferred alternative is strncpy(), which allows you to tell the function what is the size of the destination buffer so it would not copy more than that.

MS now has created alternatives to classic standard C functions, and most of them just have a buffer size as an additional parameter. The names are just like the current ones, but with the prefix "s_" (e.g., sprintf -> s_sprintf).

I am not sure why but the fact that MS did anything with classic C functions scares me to death. (MS should have taken the time to get Vista working correctly). I did however rewrite some C functions to eliminate buffer size issues. One was gets(). My get_string() function takes care of the buffer issue.