On Fri, 2010-08-20 at 06:35 -0700, José Fonseca wrote:
> 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/*
Yeah, I think it's a better plan to suck the foundational stuff out of
util/ and os/ and turn that into a new compatibility layer that both
mesa and gallium can use.
The os/ stuff is fairly clean, but util is a mix of various unrelated
helpers which need to be separated.
Keith
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
