[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> I'm talking about the ones that don't have any known problems. Yes,
certain
> functions are inherently unsafe. But memcpy? fopen? printf? As long as
you
> use them properly, how are they unsafe? You can make anything unsafe if
you
> don't use it right.
Actually, there is a well-known problem with printf():
char *s = "The character sequence `%s' is a printf() format specifier.\n";
printf(s);
But this is something that is well documented and I don't see how it's easy
to fix anyway (except by requiring that a format specifier be always
present, ie it has to be printf("%s", s);).
> deprecating sprintf in favor of snprintf. But deprecating memcpy in favor
of
> memcpy_s, fopen in favor of fopen_s. Things like that.
That's disgusting. But, lets be fair for a moment:
void *memcpy(void *dest, const void *src, size_t count);
errno_t memcpy_s(void *dest, size_t sizeInBytes, const void *src, size_t
count );
They're quite different in taking the size of the buffer as a parameter.
For fopen_s() I'm not convinced that the change is so sensible and likewise
for printf_s() and it's ilk.
> True. But even though Microsoft doesn't say what the new incompatiblities
are,
From MSDN:
#
Parameter Validation. Parameters passed to CRT functions are validated, in
both secure functions and in many preexisting versions of functions. These
validations include:
*
Checking for NULL values passed to the functions,
*
Checking enumerated values for validity,
*
Checking that integral values are in valid ranges.
Doesn't really justify creating a new function IMO, if the value checked
for really is a bug.
*
Sized Buffers. The secure functions require that the buffer size be
passed to any function that writes to a buffer.
This is somewhat sensible.
#
Filesystem security. Secure file I/O APIs support secure file access in the
default case.
#
Windows security. Secure process APIs enforce security policies and allow
ACLs to be specified.
These are far too fague to be able to pass judgement on them.
#
Format string syntax checking. Invalid strings are now detected, for
example using incorrect type field characters in printf format strings.
Good thing, but I don't see how it needs a new function...
#
Additional security enhancements are described in the documentation for
each function.
No it's not. They just link to the global list I just read...
> I'd still say there was no reason to deprecate the original functions.
Yes, I completely agree. Even if some of the changes make sense, they
should not deprecate the originals. There are many GNU extensions that
offer more secure versions of standard libc functions, but they never made
standard functions deprecated.
The only reason to do otherwise is to encourage people to write
non-portable code.
> Who knows, maybe if enough people don't fall into this trap of using the
new
> "secure" functions, Microsoft will rethink this idea, un-deprecate these
> functions, and we could then continue working with MSVC.
I'm somewhat pessimistic, to be honest. Be prepared to see newbies write
code using printf_s() and complain that it doesn't work on platform X
where X is not Windows.
Maybe it's a good idea to write up a paragraph in the `writing
cross-platform code' section of Allegro's manual?
Evert