On Wed, Jun 7, 2017 at 4:42 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Wed, Jun 7, 2017 at 4:34 PM, Marek Olšák <mar...@gmail.com> wrote:
>> On Wed, Jun 7, 2017 at 10:28 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> On Wed, Jun 7, 2017 at 4:22 PM, Marek Olšák <mar...@gmail.com> wrote:
>>>> On Wed, Jun 7, 2017 at 10:12 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>>>> This creates string lifetime issues... should probably document that
>>>>> the pointer returned by get_vendor and get_name are supposed to last
>>>>> for the lifetime of the screen.
>>>>
>>>> Was the lifetime of the string not always guaranteed?
>>>>
>>>> Most drivers use a statically-declared string or a literal string. I
>>>> think the lifetime has always been at least the same as the lifetime
>>>> of pipe_screen.
>>>
>>> Previously it was stored in st_context, so the lifetime only had to be
>>> for "a little while", until the next line of code saved it off. The
>>> nouveau implementation is, for better or worse, currently:
>>>
>>> static const char *
>>> nouveau_screen_get_name(struct pipe_screen *pscreen)
>>> {
>>>    struct nouveau_device *dev = nouveau_screen(pscreen)->device;
>>>    static char buffer[128];
>>>
>>>    util_snprintf(buffer, sizeof(buffer), "NV%02X", dev->chipset);
>>>    return buffer;
>>> }
>>>
>>> So while the pointer will remain valid, it will potentially change for
>>> different screens that are created within the same process space.
>>> (Which could happen with EGL, or maybe other odd scenarios.)
>>
>> I think that should be fixed in drivers. You can, for example, put the
>> string into your screen structure.
>
> Fully agreed. And as you probably realize, it's a rare scenario. Just
> looking to get some documentation saying that the pointers should
> remain valid for the lifetime of the screen.

And more importantly, not just the pointers, but also the values
contained within.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to