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

José Fonseca jfonseca at vmware.com
Fri Aug 20 05:39:00 PDT 2010


On Fri, 2010-08-20 at 05:09 -0700, Luca Barbieri wrote:
> > The advantage of having a prefix is that it makes it easy to detect when
> > people don't include the proper headers such as u_string.h, and it
> > guarantees one can wrap around even buggy OS implementations without
> > doing #define magic. It also allows to easily add wrapping.
> 
> It is indeed possibly advantageous if the platform provides a broken
> implementation, but as you point out #define magic can solve this, and
> I expect/hope this to be a rare exception.
> 
> A price for this is however paid by everyone all over the codebase,
> while the #define magic (or any other magic) would be localized.

Speaking of localized, I remembered another problem: locales. By using
the . By using our own versions we garantee that a "." is always a "."
and not "," or whatever.

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.

> The best approach would probably be to decide this on a case-by-case
> basis, and in some cases I'd argue that the current state is obviously
> not the right choice:
> 1. INLINE is very frequently used, and defining "inline" instead is
> actually simpler, and is less confusing for source
> analysis/highlighting 

I agree. Furthermore C99 defines inline already.

> tools.
> 2. "memcmp" is currently OK, but one is supposed to use "util_strcmp"
> instead of "strcmp", which looks quite hard to remember and get right
>
> BTW, MSDN documents strcmp to be available at least in user mode and
> u_string.h provides his own implementation anyway.
> Did Microsoft actually manage to somehow provide a broken strcmp?
> If not, then the system implementation is likely to be much faster due
> to target-specific optimizations.

No. But it provides a broken sprintf (in the kernel it didn't even
support floats; for userland I no longer recall if/what problems it
has).

The other strxxxx were renamed to util_strxxx for consistency whithin
that module. 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).


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.


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. Especially now that it's not only mesa + gallium, but also
mapi and glsl2 which have some independence and also could benefit the
portability wrappers.

It would be nice to standardize, either on a cgrt_ prefix for everything
in there, or vanilla CRT symbols everywhere. So that there is no more
guessing.

I really don't have a strong preference either way: so I'd like to hear
what the maintainers of these modules (Brian, Keith, Olv, Ian) think.


Jose

[1] Common Graphics RunTime



More information about the mesa-dev mailing list