Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-Id:	<200102020851.JAA10812@mailhost.ri.silicomp.fr>
To:	Earnie Boyd <cygwin AT cygwin DOT com>
cc:	Eric PAIRE <eric DOT paire AT ri DOT silicomp DOT com>
Subject:	Re: misdefined macro _T in winnt.h
In-reply-to:	Your message of Thu, 01 Feb 2001 11:22:58 -0500.
	<3A798D62 DOT A9D8B309 AT yahoo DOT com>
Mime-Version:	1.0
Date:	Fri, 02 Feb 2001 09:51:28 +0100
From:	Eric Paire <paire AT ri DOT silicomp DOT fr>

Earnie Boyd wrote:
> 
> Eric Paire wrote:
> > 
> > Sorry folks, I have forgotten to tell you to compile it with the _UNICODE
> > and UNICODE defined. Here is a corrected  version that has some problems
> > when compiled:
> > 
> > ------  Cut Here  ------  Cut Here  ------  Cut Here  ------  Cut Here  ------
> >  #define __DIR "dir"
> > 
> >  #include <stddef.h>
> >  #include <tchar.h>
> >  main() {
> >         size_t len = wcslen(_T(__DIR)) + wcslen(_T("dir"));
> >         size_t len = wcslen(_TEXT(__DIR)) + wcslen(_TEXT("dir"));
> >         exit(len);
> >  }
> > ------  Cut Here  ------  Cut Here  ------  Cut Here  ------  Cut Here  ------
> > 
> > You will see that the problem is around the evaluation of the __DIR macro
> > (there is no problem with "dir"), both for _TEXT and _T. In addition, this
> > should be fixed also for the _T and _TEXT definitions in <winnt.h>, which
> > should be coherent with those in <tchar.h> (They are not for now, as _T is
> > defined either as an object-like macro (in <winnt.h>) or as a function-like
> > macro (in <tchar.h>)).
> > 
> > If you want me to provide you with a patch (and a ChangeLog), let me know...
> > 
> 
> No, I don't need a patch.  I do need to know if
>   L"dir" == L("dir")
>  
> ?  The problem with this macro is the use of the macro concatenation ##
> and the order in which the macros are resolved.  Currently we have
>   #define _T(x) L ## x
> and if you pass a macro FOO as an argument to this macro you get LFOO
> returned and not the value of FOO appended to L.  If I change this to
>   #define _T(x) L(x)
> then I get returned L("bar") where "bar" is the value of FOO.  This
> allows the program to compile but does L"bar" == L("bar")?
> 
I don't agree with your question. From my point of view, the question is
whether (with #define FOO "foo") _T(FOO) is expanded as L"foo" or as LFOO,
in other words, whether macro _T is processed before its contents or the
contents before _T.

Under MSC, the answer is that _T(A) is expanded towards L"foo" and under
cygwin towards LFOO, which is incompatible; so you cannot compile such
program under cygwin.

The patch I wanted to proposed was ABSOLUTELY not the same as yours:

------  Cut Here  ------  Cut Here  ------  Cut Here  ------  Cut Here  ------
#ifdef _UNICODE
#define __TEXT(q) L ## q
#else
#define __TEXT(q) q
#endif

// Force the evaluation of q before the evaluation of __TEXT
#ifndef _TEXT
#define _TEXT(q) __TEXT(q)
#endif

// Notice that _T must absolutely behave in the same way as _TEXT
#ifndef _T
#define _T(q) __TEXT(q)
#endif
------  Cut Here  ------  Cut Here  ------  Cut Here  ------  Cut Here  ------

With this patch,

_T("foo") expand as L"foo"
_T(FOO) expands also as L"foo"

-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web  : http://www.ri.silicomp.com/~paire  | Groupe SILICOMP - Research Institute
Email: eric DOT paire AT ri DOT silicomp DOT com         | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71               | F-38610 Gieres
Fax  : +33 (0) 476 51 05 32               | FRANCE


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -