[Piglit] [PATCH] glsl-1.10: Verify that C99 digraphs aren't treated specially in GLSL

[Kenneth Graunke]

On 12/08/2011 05:38 PM, Ian Romanick wrote:
> On 12/08/2011 01:55 PM, Kenneth Graunke wrote:
>> On 12/07/2011 03:32 PM, Ian Romanick wrote:
>>> From: Ian Romanick<ian.d.romanick at intel.com>
>>>
>>> Right now the digraph-close-bracket tests cause a segfault (or an
>>> assertion failure) in Mesa's GLSL compiler.
>>>
>>> Signed-off-by: Ian Romanick<ian.d.romanick at intel.com>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43564
>>> Cc: Yi Sun<yi.sun at intel.com>
>>
>> Ian,
>>
>> I was never clear whether digraphs should or shouldn't be interpreted.
>> I think the only argument in favor is the "as is standard for C++
>> preprocessors" text, and I thought digraphs were done translated by the
>> C++ preprocessor.  Which is pretty weak.  But the symbols making up the
>> digraphs are in the character set, so I'm uncertain.
>>
>> Can you back this up somehow?  Spec language, test cases from other
>> suites, or other driver behavior would suffice.  I definitely prefer not
>> having to interpret them.
> 
> I seem to recall the spec saying the trigraphs are not interpreted
> specially, and I though digraphs were only in C99 (not C++).  I'll dig
> some more.

Ah...you're right.  From the GLSL 4.20 spec, page 10 (page 16 of the
PDF): "There are no trigraphs."  I'll take that as a clarification.  It
doesn't explicitly mention digraphs, however.

According to my (draft but nearly complete) copy of the C++98 spec,
section "2.5 Alternative tokens [lex.digraph]" does include <% and %>.
So they're not just C99.  But it also includes things like "compl,"
"bitand," "or_eq," and so on...which definitely aren't part of GLSL.

So, seeing as GLSL explicitly omits trigraphs and doesn't explicitly
define any alternate token spellings, it's probably safe to assume they
have no special meaning.