Dimitrie O. Paun [EMAIL PROTECTED] writes:
Now, on a different note, you pointed out an interesting thing: we need to
test mixed A/W cases. We thus have four possible cases:
(A,A), (A,W), (W,A), (W,W)
Should we test all of them?
We must test everything that is part of the expected
--- Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Andriy Palamarchuk [EMAIL PROTECTED] wrote:
Attached version of the C testing framework, which
is
implemented with using TCHAR.H macros, so it is
portable between ASCII and Unicode platforms. Also
implemented test which can be used to
- to have the same
ASCII/Unicode mode processing for everything.
Otherwise I'd have to explicitely call ASCII functions
for file names processing, probably do A-W
conversion.
More comments later :)
Look forward :-)
Andriy Palamarchuk
__
Do You
Just commenting from the side-lines :-)
On Tue, 22 Jan 2002, Andriy Palamarchuk wrote:
[...]
Using function instead of macro won't work in all the
cases, e.g. in this one:
_TCHAR buf[100] = _T(foo)
I would rather avoid such constructs precisely because of the
compiler support
Andriy Palamarchuk [EMAIL PROTECTED] writes:
In the worst case people, who do not have such
compiler will be able to run tests in ANSII mode only.
That's clearly not an option.
Here I don't agree with you. Programming with TCHAR is
*exactly* the same as programming with WCHAR, but with
busy
at the moment. I guess this means more late nights... :)
-- Why do you do:
_T(__FILE__)
Files are ASCII, no need to _T them.
__FILE__is a macro which is expanded to file name. I
use _T with it for simplicity - to have the same
ASCII/Unicode mode processing for everything
On Tue, 22 Jan 2002, Alexandre Julliard wrote:
But we want people to think twice, and write a test adapted to the
function they are testing; you don't test ASCII and Unicode the same
way, except superficially.
With all due respect Alexandre, I can't understand your point. When does
the
Dimitrie O. Paun [EMAIL PROTECTED] writes:
With all due respect Alexandre, I can't understand your point. When does
the _semantics_ of the function differ based on the string
encoding???
Functions that take strings usually do something with them, so this is
part of the function semantics,
Attached version of the C testing framework, which is
implemented with using TCHAR.H macros, so it is
portable between ASCII and Unicode platforms. Also
implemented test which can be used to test ASCII and
Unicode API.
As I found out creating ASCII/Unicode portable code
requires much more
think it is worth wasting
more time arguing about it...
Yeah.
So... let's see.. how much processing time did we waste going from
ASCII-Unicode-UTF8... h 2*N (where N is number of
characters).
I think I can live with that. Hell, I'd even be willing to
live with more
than
On Sat, 29 Apr 2000, David Elliott wrote:
Which would be generated from a function like:
/* START ATOW */
DWORD BarW( LPSTR lpString1, DWORD cbString1 )
/* END ATOW */
{
/* DO STUFF */
return 0;
}
I don't really see a need for this kind of ugliness. We know that a xxxW
Now, I initially started this thread by saying that I was
trying to _eliminate_ our internal API as much as possible,
and simply use the std. Windows API. My motivation is twofold:
1. The Win API is huge enough as it is, it is no point in inventing
functions with new semantics for no good
Furthermore your solution will require close to every
function dealing with string to be rewritten.
Any solution will, since most things are implemented W - A now.
Well at least 172 functions are.
I implemented a simple check in winapi_check that got the following results.
: advapi32: RegisterEventSourceA: illegal call to
HEAP_strdupAtoW (ASCII - Unicode)
dlls/advapi32/eventlog.c: advapi32: RegisterEventSourceA: illegal call to
RegisterEventSourceW (ASCII - Unicode)
dlls/advapi32/registry.c: advapi32: RegCreateKeyExA: illegal call to
copy_nameAtoW (ASCII - Unicode)
dlls
[I, forwarded it to the list, since I don't believe you meant
it as a private mail]
From: "Patrik Stridvall" [EMAIL PROTECTED]
The only way your solution can be justified is in terms of
efficiency, it sucks for debugging and readabillity as Marcus
pointed out.
Look, I am not in love
-- no support for other encodings (say for Asian languages
which may need more bytes than Unicode supports)
Speaking of Asian languages, reminds me.
wchar_t in Unix is 32-bit long.
I have never really understod how
all these different formats work.
Anybody care to enlightment me?
OK, I can
On Thu, 27 Apr 2000, Patrik Stridvall wrote:
-- no support for other encodings (say for Asian languages
which may need more bytes than Unicode supports)
Well that is nonsense. Unicode incorporates Asian languages.
Speaking of Asian languages, reminds me.
wchar_t in Unix is 32-bit
On Thu, 27 Apr 2000, Ove Kaaven wrote:
On Thu, 27 Apr 2000, Patrik Stridvall wrote:
-- no support for other encodings (say for Asian languages
which may need more bytes than Unicode supports)
Well that is nonsense. Unicode incorporates Asian languages.
You will find many speakers
From: "Patrik Stridvall" [EMAIL PROTECTED]
Yes, we need to fix them that is not a big deal.
Perhaps we can autogenerate them somehow.
The spec files know or can be told what is
strings or what is not.
Auto-generation will make me happy, because I think it is the only way
to (1) remove
From: "Patrik Stridvall" [EMAIL PROTECTED]
Yes, we need to fix them that is not a big deal.
Perhaps we can autogenerate them somehow.
The spec files know or can be told what is
strings or what is not.
Auto-generation will make me happy, because I think it is the only way
to (1)
On Wed, Apr 26, 2000 at 10:59:20AM +0800, Dmitry Timoshkov wrote:
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
[...]
I think we should be a lot more agnostic about the string encoding. What I
mean is that we should have only one function that works with all encodings,
which takes as the first
Along with transition to internal unicode implementation, I think
it should be possible to separate 16-bit parts from 32-bit ones.
I would also love for this to happen because, IMO, it clutters the code. But
my opinion is biased, since I don't care much about the 16bit part -- I
would like to
We have the following situation: we receive strings as
arguments; their
encoding is not explicit with every string, but rather is
implicit by the
entry
point.
Please note that there are some cases in which the encoding is
determined by the user specified OS version.
I'm not saying that
From: "Patrik Stridvall" [EMAIL PROTECTED]
Please note that there are some cases in which the encoding is
determined by the user specified OS version.
Yeah, these are trivial to deal with, once we can mark the encoding.
Now, we can do two things:
1. [eager] conver at the entry point
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
[...]
I think we should be a lot more agnostic about the string encoding. What I
mean is that we should have only one function that works with all encodings,
which takes as the first argument the encoding used by the other strings
passed in as arguments:
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
But this transition will consume a lot of time and efforts, because
currently Wine does all work in reverse order.
Yes, but once we set up a pattern, we can have a gradual transition.
Along with transition to internal unicode implementation, I think
26 matches
Mail list logo
