On Fri, 2010-08-20 at 06:17 -0700, Luca Barbieri wrote:
> > 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?
No. Some people would have an indigestion, and it Gallium itself would
benefit from the cleanup of seperating OS/debug/ADT stuff from the
gallium speific utilities. ATM everything is a big spaghetti inside
auxiliary/*
> 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.
Yes. That would be a good follower.
> 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
Perhaps. Anyway, one thing at a time.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
