[cfe-commits] Requesting review of MS compatibility patch (fixes bug 11789)

[Richard Smith]

On Mon, Jun 11, 2012 at 6:31 PM, Aaron Wishnick
<aaron.s.wishnick at gmail.com>wrote:

> On Jun 11, 2012, at 9:15 PM, Richard Smith wrote:
>
> Do we need __LPREFIX() support for anything else? If not, it would seem a
> lot simpler to add support for a L__FUNCTION__, which behaves just like
> __FUNCTION__ but produces a wide string.
>
>
> MSVC also supports some other predefined expressions, like __FUNCDNAME__,
> __FUNCSIG__, etc, so it would be necessary to provide the wide versions of
> any of those.
>

OK, but we don't yet support any of those, and adding the L version at the
same time would probably not be a massive undertaking.


> Also, though it's undocumented, there are people who know about it and use
> it, e.g. see [1] and [2]. Also, my hope for this patch is to increase
> compatibility with the MSVC headers, as well as other projects that only
> target Microsoft's compiler, and there's the potential for those other
> projects to make use of the __LPREFIX extension.
>

If that's a problem in practice, we could provide a predefined __LPREFIX
macro:

#define __LPREFIX_impl(x) L ## x
#define __LPREFIX(x) __LPREFIX_impl(x)


> I agree though, it would be much simpler to add L__FUNCTION__, so I guess
> it's up to you where you want to set the bar.
>

It certainly seems reasonable for us to provide compatibility with
constructs which are used in MSVC headers, such as L ## __FUNCTION__. The
argument for providing perfect compatibility (to handle situations we've
not seen) is weaker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120611/676e81d2/attachment.html>