> Hasn't this already happened somewhere - util/u_snprintf.c ? Indeed, I'll fix it to use those.
There's something (independent from this) that bugs me though. Why does Gallium feel the need to implement all this stuff with ad-hoc names, instead of, for instance, just implementing a function called "sprintf" if the platform doesn't provide it? Other similar instances are the "INLINE" macro instead of an "inline", "MALLOC" instead of "malloc", PIPE_ARCH_X86 instead of "__i386__", and surely many others. On the same note, if, for instance, "stdio.h" doesn't exist, one can just write an header called "stdio.h" and add that directory to the include path on the affected platform, instead of inventing another header name. The result of this is that the codebase is cluttered with non-standard (and often ugly) conventions, and it is trivial to write code that works perfectly on Linux, but not on other platforms, because it uses the standard naming instead of the strange Gallium-specific names (as you can see in the case of this patchset). As a byproduct of this, hardware drivers tend to drift away for this unusual convention, since they are never built for Windows. For instance, nouveau drivers use "inline" instead of the "INLINE" that Gallium code is supposed to use. Given that I suspect that essentially no one outside VMware does Mesa development on a non-Unix platform, it seems a good idea to make sure that such code also works on Windows automatically without needing to be fixed each time. Would a set of regular expressions plus simple patches that tries to fix all instances of this all over the codebase be positively accepted? I seem to recall that a similar substitution was applied to the non-Gallium parts of the Mesa. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
