[Mesa-dev] Merging gallium-rect-textures and debug-refcnt?

[Luca Barbieri]

> And define magic is very brittle. Especially with C++: you #define
> printf to be something else, but nothing prevents a class or a namespace
> to have the printf symbol in its scope.

Yes, but hopefully that's going to be very rare.

Alternatively, you can do this:
1. Compile with cl /Dsprintf=dontuse_windows_sprintf

2. Put in a header:
#include <windows.h>
#undef sprintf

static __forceinline sprintf(...)
{
 my_vsprintf(...)
}

3. Put in a C file:
void my_vsprintf()
{...}

If the header is not included, linking will fail (due to the reference
to dontuse_windows_sprintf), otherwise the custom version will be used
whenever sprintf is called, while still having sprintf as a (forced
inline) function.

It's also possible to ask the compiler to include the header with a
command line switch (-include in gcc), so that fully standard code
will work.

As a third option, you can have a build step that creates a patched
copy of the Windows headers, kind of like GCC's fixincludes.

> And again, using the CRT for strings is subject to the
> current locale. Care has to be taken when using it for stuff other that
> debug printing (e.g., shader parsing, which was exactly the bug what
> happened before in Mesa).

Only some functions respect the locale.

The glibc documentation says this:
     `strcmp' does not take sorting conventions of the language the
     strings are written in into account.  To get that one has to use
     `strcoll'.

And MSDN says this:
In locales for which the character set and the lexicographic character
order differ, use strcoll rather than strcmp for lexicographic
comparison of strings according to the LC_COLLATE category setting of
the current locale. Thus, to perform a lexicographic comparison of the
locale in the above example, use strcoll rather than strcmp.
Alternatively, you can use strxfrm on the original strings, then use
strcmp on the resulting strings

> Another example are math.h's sinf/cosf etc. It's indeed quite convenient
> to have the standard names. But some CRTs use #defines other inlines,
> and then suddenly different versions of the compiler/CRT do different
> things.

Isn't that going to be equivalent if the macros use the argument only once?

> I still have the plan to make a CGRT [1] module to centralize all
> existing OS portibility and abstract data types used everywhere in the
> mesa tree.

How about just making everything in the Mesa tree depend
unconditionally on Gallium, and let them use auxiliary/, os/, etc.
directly?

In addition to all the duplicated portability code, there are some
other things like util_format that Mesa would benefit from using,
instead of having its own inferior version.
It would also be great if Mesa IR and TGSI were unified, since their
minor differences don't seem to warrant having two IRs.4444