Re: Is the following little function UNICODE-safe? ...
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 26 Mar 2008 15:11:05 -0500
Several problems, see below...
On Wed, 26 Mar 2008 10:32:51 -0700 (PDT), ".rhavin grobert" <clqrq@xxxxxxxx> wrote:
I'm trying to write my code in a way that doesn't makes it very hard****
to switch later to UNICODE,
but sometimes i've funcs that will be called very often, so they have
to be *fast*
may i expect that a char[] is correctly translated when this fn is
called in a UNICODE-env or is some _T()-magic required?
//-----------------------------------------------------------------------
// get the default extension associated with the files type
LPCTSTR CInfFile::ExtensionGetDefault() const {
DWORD dwDefID = CFZFile::IdentifierGetDefaults(TypeGet());
What is this supposed to mean? Note that in ANSI, this would represent three characters
terminated by a NUL character, but in Unicode, it would represent a single character at
most, and the proper termination does not exist.
****
dwDefID &= 0x00FFFFFF;****
This clearly makes it obvious that you think you are returning 8-bit characters. This
can't work.
****
return reinterpret_cast<char*>(&dwDefID);****
This is incorrect. You have a prototype which CLEARLY states the return type is "LPCTSTR"
yet here you both use an incorrect data type (char) and don't have a const cast. The
OBVIOUS correct response would be
return reinterpret_cast(LPCTSTR)(&dwDefID);
but in fact it is FAR worse than this.
You have used a local variable in a function, and you are returning a pointer to a local
variable. The value is COMPLETELY WITHOUT MEANING upon return!
A DWORD can hold at most 3 8-bit characters or 1 16-bit character.
Why do you think file extensions are 3 characters long? What about ".html", ".vcproj" and
similar extensions? The 3-character assumption has been dead for over 15 years.
Then, you have to make sure that the CFZFile::IdentiferGetDefaults(TypeGet()) can ONLY
return 8-bit characters; that is not always a safe assumption in a Unicode environment!
Why is it encoding a string as a DWORD anyway? But if it DOES return 8-bit characters,
why are you using a static and returning a pointer to it? It would make more sense to
write
CString CInFile::ExtensionGetDefault() const {
DWORD dwDefID = CFZFile::IdentifierGetDefaults(TypeGet());
dwDefID &= 0x00FFFFFF;
return CString((LPCSTR)&dwDefID);
}
It is IMPOSSIBLE to return a pointer to a stack variable, but do NOT be tempted to add the
word 'static' to the declaration. This would create a program which would be an example
of worst-possible-programming-methodology, and it would be erroneous in another way.
joe
****
}Joseph M. Newcomer [MVP]
thx, -.rhavin;)
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- Is the following little function UNICODE-safe? ...
- From: .rhavin grobert
- Is the following little function UNICODE-safe? ...
- Prev by Date: Re: Is the following little function UNICODE-safe? ...
- Next by Date: Re: Is the following little function UNICODE-safe? ...
- Previous by thread: Re: Is the following little function UNICODE-safe? ...
- Next by thread: OT: Can't set breakpoint
- Index(es):
Relevant Pages
|
