[fpc-other] [fpc-pascal] FPC Graphics options?

[Nikolay Nikolov]

On 05/24/2017 04:44 PM, Karoly Balogh (Charlie/SGR) wrote:
> Hi,
>
> On Wed, 24 May 2017, Nikolay Nikolov wrote:
>
>
>> this is bad language design. Bonus points for the fact that writing this
>> ugliness:
>>
>>     if (5 == i)
>>       do_something();
>>
>> is considered a very good practice by some people, just because it
>> prevents you from being burned if you write if (5 = i) instead :)
> These are nicknamed Yoda conditions. :)
ROTFL, didn't know that :)
>
>> 4) the badly designed standard library. Even though C "strings" suck by
>> design, the library functions, that operate on them have extra hidden
>> traps. For example, using strcpy is unsafe, because it doesn't check the
>> size of the destination buffer, that's why you must use strncpy.
>> However, this code:
>>
>> char dest[1000];
>> strncpy(dest, src, sizeof(dest));
>>
>> is still unsafe. Why? Because if src is 1000 characters or larger, even
>> though strncpy will not overwrite past the end of the dest array, it
>> will _not_ put a null terminator in the dest array. On top of that, it
>> is also suboptimal - if src is shorter, strncpy will fill the entire
>> array past the end of the string with null characters. So, if src is a
>> 10 character string, strncpy will write 990 null characters, filling the
>> area between dest[10] and dest[999], wasting CPU cycles on that.
> OK, this is also beautiful, thanks again. :) BSDs seem to have strlcpy()
> tho', which works around both defects mentioned here, but that's non
> standard obviously, because who needs standard functions which make sense.
> :)
Of course, it's still not standard, because, according to their logic, 
string truncation is unsafe, while buffer overflows are somehow safer, 
for some strange reason. I've seen discussion like that, unfortunately I 
didn't keep the link, so that you can laugh. :) And, of course, strncat 
is entirely inconsistent with strncpy:

- strncat always ensures there's a null terminator in the destination, 
while strncpy doesn't guarantee it.
- strncat doesn't fill the rest of the buffer with nulls, when there's 
leftover space, while strncpy does.
- strncat's size parameter must be the maximum number of character to 
add to the destination buffer, minus the null character (so dest must 
have space for strlen(dest)+size+1 bytes), while strncpy's size 
parameter is the size of destination buffer.

Thanks to things like that it's mindblowingly difficult to learn how to 
write correct code, that isn't vulnerable to buffer overflows, using C 
"strings", and most people don't do it. They think they do, but they 
always get caught in some of these traps, without even realizing it and 
that's where almost all of the buffer overrun security exploits come from.

Nikolay