Hi,
On Wed, 24 May 2017, Nikolay Nikolov wrote:
> Yes, this is one of the horrible things I have beef with. I have several.
> (....)
> 2) the fact that the array size is not exactly part of the type. In case
> you're wondering what this means, if you declare:
>
> int a[5];
>
> sizeof(a) gives you the correct size of the array. However, if you pass
> this array as a parameter to a function:
>
> void func(int array_param[5])
> {
> // inside the function, sizeof(array_param) gives you the size
> of a pointer, and not the array size
> }
>
> That's one of the reasons you can't add range checking to C compilers.
Ah, I love this. :) Thanks for this, I didn't know. Will put it on my
list. :)
> 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. :)
> 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.
:)
Charlie
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
