[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] MSVC 8 cl flags
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Sat, 20 Aug 2005 01:57:27 -0700
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=hwVjosvxsLO28WzGE7Qe3b+nbyzte/ATyePo+koLQ60cCDtoxDyBcM2DNghjKTgDxk7SvBE5qZUUTByQ5uUKF+y+5/xuLGlaresjw78H0+W47eEN4fZGNKwHeyPHriGRTEjiAuE1aZIVEjOkUivRqWEArU703gcc90TAizJs73c=
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.