Prev: #define _CRT_SECURE_NO_DEPRECATE doesn't work
Next: enum problem - getting C4482
From: Norman Diamond on 30 May 2006 01:47
"John Carson" <jcarson_n_o_sp_am_(a)netspace.net.au> wrote in message
news:Or$TLQ5gGHA.1884(a)TK2MSFTNGP03.phx.gbl...
> "Norman Diamond" <ndiamond(a)community.nospam> wrote in message
> news:uLGQUd4gGHA.4452(a)TK2MSFTNGP05.phx.gbl
>> "John Carson" <jcarson_n_o_sp_am_(a)netspace.net.au> wrote in message
>> news:OmrNmqygGHA.1320(a)TK2MSFTNGP04.phx.gbl...
>>> "Norman Diamond" <ndiamond(a)community.nospam> wrote in message
>>> news:udOyprwgGHA.1856(a)TK2MSFTNGP03.phx.gbl
>>>>
>>
>> ISO C has a function snprintf which counts bytes (because ISO misspells
>> the word byte as "character") but ISO C++ doesn't have function snprintf.
>
> It would help if you identified what version of ISO C you are referring
> to. I presume you mean C99.

Yes C99. I don't recall if C90 was the same, though still have a dead tree
version of a draft of ANSI Classic at home somewhere.

>> [MSDN:]
>>>>> _snprintf_s returns the number of characters stored in buffer, not
>>>>> counting the terminating null character. _snwprintf_s returns the
>>>>> number of wide characters stored in buffer, not counting the
>>>>> terminating null wide character.
>>>>
>>>> This looks terrible. Actually _snwprintf_s looks mostly OK, since the
>>>> programmer wants to do calculations on the number of wide characters
>>>> and keep track of how much space remains in the buffer. But why does
>>>> _snprintf_s return the number of characters instead of the number of
>>>> bytes?
>>>
>>> Um...because a byte and a char have the same size?
>>
>> No. Even though a byte and a char have the same size, a character
>> doesn't. ISO uses the word "character" more or less interchangeably with
>> byte and char, but real world programs cannot. In ANSI environments each
>> character occupies one or two bytes depending on the individual character
>> and the code page. In UTF16 each character occupies two bytes except for
>> surrogate pairs.
>
> I take it you are referring to Microsoft's multibyte characters for
> Japanese characters and such.

In Microsoft's ANSI environments yes. Had I been referring to other
multibyte environments, appropriate newsgroups surely wouldn't be hosted on
a Microsoft server ^_^

In Microsoft's Unicode environments no (though surrogate pairs require the
same sort of processing as multibyte characters do in ANSI environments).

> I note that sprintf_s is documented to return the number of bytes written.

Two more odd things here:

1. You're half right. The MSDN page on sprintf_s contradicts itself on the
return value. In one paragraph it says the number of characters written and
in the next paragraph it says the number of bytes written.

2. I wonder why this function name has no leading underscore. I can't find
sprintf_s in either C99 or C++03.

> It would be surprising if sprintf_s and snprintf_s returned different
> things,

You get surprised easily ^_^

> so I suggest you test this to see what is really returned.

Yeah no kidding. 75% of MSDN is accurate, but we don't know which 75% until
we experiment. Sigh.

> If the function does return the number of characters rather than the
> number of bytes, then this may not be as inconvenient as it appears.

But in an ANSI environment the program still allocates the buffer as some
number of bytes. We can't just say "give me a buffer big enough for 500
characters" when we don't know what the characters are. Though I guess we
could allocate 1001 bytes for that. In Unicode we'd allocate 501 WCHAR_Ts
which would occupy 1002 bytes.

> With new functions such as strcat_s/_mbscat_s, you do not have to tell the
> function how much space remains; you only have to tell it the total size
> of the buffer.

I think you're right about _tcscat_s being secure enough. If I didn't want
the CPU to traverse the buffer over and over again I wouldn't be using a
language based on C. I've just finished changing my code that used to call
_sntprintf to copy into the appropriate parts of the buffer, to call
_sntprintf_s instead, but this has been a premature optimization all along
and it doesn't suit the spirit of C. (I'm not complaining to you about
this, I'm equally cynical about C as everything else.)

First  |  Prev  | 
Pages: 1 2
Prev: #define _CRT_SECURE_NO_DEPRECATE doesn't work
Next: enum problem - getting C4482