This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: misdefined macro _T in winnt.h


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.paire@ri.silicomp.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]