Re: [AD] MSVC 8 cl flags

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Saturday 20 August 2005 01:19 am, Evert Glebbeek wrote:
> 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);).

GCC throws a warning when you try to pass a non-literal string to a printf 
format specifier and don't specify extra arguments.

char *s = "The character sequence `%s' is a printf() format specifier.\n";
printf(s);

GCC would warn you about that. However, you could do:

char *s = "The character sequence `%s' is a printf() format specifier.\n";
printf(s, "%s");

And it'll allow it without warning.

> 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.

Okay, then I missed that. Seems odd that it'd take two length parameters, when 
one of them (the larger) will be indesciminently ignored. Might make things 
cleaner from a coding perspective, but it's effectively a null-point.

memcpy_s(dst, dst_byte_size, src, src_bytes_to_copy);

is the same as:

memcpy(dst, src, min(dst_byte_size, src_bytes_to_copy));

> Doesn't really justify creating a new function IMO, if the value checked
> for really is a bug.

Exactly. And considering they could've done something like Allegro does (check 
for valid parameters in debug, and not in release (where appropriate)) for 
libc..

>     *
>       Sized Buffers. The secure functions require that the buffer size be
> passed to any function that writes to a buffer.
>
> This is somewhat sensible.

Ehh, kinda yeah. Though many libc functions that deal with buffers have got 
buffer size arguments already (sprintf->snprintf, strcpy->strncpy, etc), and 
it's adding buffer size arguments where you don't really need them 
(memcpy_s).

> Maybe it's a good idea to write up a paragraph in the `writing
> cross-platform code' section of Allegro's manual?

Or perhaps in the Windows-specific section, warning that the _s functions are 
non-portable. I'm not sure how MinGW plans on handling this.




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/