Looks like the change happened as of 4.40. I checked as far back as
GLSL 1.50, and it was the older "you can do whatever" wording
everywhere there:
"""
All macro names containing two consecutive underscores ( __ ) are
reserved for future use as predefined
macro names. All macro names prefixed with “GL_” (“GL” followed by a
single underscore) are also
reserved
"""
It never says it's an error to use these. Oh well.
-ilia
On Wed, Aug 26, 2015 at 3:01 AM, Dave Airlie <airl...@gmail.com> wrote:
> On 26 August 2015 at 16:55, Dave Airlie <airl...@gmail.com> wrote:
>> On 26 August 2015 at 16:48, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> On Wed, Aug 26, 2015 at 2:38 AM, Dave Airlie <airl...@gmail.com> wrote:
>>>> From: Dave Airlie <airl...@redhat.com>
>>>>
>>>> GL33-CTS.shaders.preprocessor.definitions.*
>>>> has 4 tests the undefine these,
>>>>
>>>> I can't find anything in the spec saying that isn't correct.
>>>>
>>>> Signed-off-by: Dave Airlie <airl...@redhat.com>
>>>> ---
>>>> src/glsl/glcpp/glcpp-parse.y | 4 +---
>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>
>>>> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
>>>> index 18e50af..77010b4 100644
>>>> --- a/src/glsl/glcpp/glcpp-parse.y
>>>> +++ b/src/glsl/glcpp/glcpp-parse.y
>>>> @@ -289,9 +289,7 @@ control_line_success:
>>>> } IDENTIFIER NEWLINE {
>>>> macro_t *macro;
>>>> if (strcmp("__LINE__", $4) == 0
>>>> - || strcmp("__FILE__", $4) == 0
>>>> - || strcmp("__VERSION__", $4) == 0
>>>> - || strncmp("GL_", $4, 3) == 0)
>>>
>>> From GLSL 4.50 page 12, section 3.3:
>>>
>>> All macro
>>> names prefixed with “GL_” (“GL” followed by a single underscore) are
>>> also reserved, and defining such a
>>> name results in a compile-time error. That said I don't see anything
>>> about redefining __FILE__.
>>
>> Okay that must be new language brought it at some point, at least 4.2
>> has older language
>> which means it should be conditional on #version on whether GL_ can be done.
>>
>> uggh, maybe I can try again :-)
>
> Ah it's all a mess, I'll run away and put the tests on the need work list.
>
> Dave.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
