[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] ESSL 3.5 Comments Compliance



> What makes you say this?  I don't see any language in Sec 3.1 or 3.3 that
> allows characters outside of the defined source character set in a GLSL ES
> 1.0 shader.

Sec 3.5 states that comments are treated syntactically as a single
space. Sec 3.3 states that the second phase of compilation is removal
of comments after string concatenation and before preprocessing.
Comments are not included as part of the grammar productions and do
not effect processing except via insertion of space/newline.

Furthermore, here is a list of invalid shader examples (due to invalid
character use) in the ESSL spec itself:

4.1.2: // declare “success” to be a Boolean
4.1.2: // declare and initialize “done”
4.2.2: // y is initialized to '2'
4.2.2: // x is initialized to '1'
4.2.2: // 'S' is only visible as a struct and constructor
4.2.2: // 'S' is now visible only as a variable
4.2.7: // Error: type 'f' conflicts with function 'f'
4.2.7: // Error: conflicts with the type 'f'
4.6.2: // a has a value a2 where possibly a1 ≠ a2
5.5: // illegal - 'x' used twice

As these characters never reach the compiler and do not participate in
identifiers or executable code, the spec is silent on their acceptable
character set. The spec does indicate that shader length is used to
determine the end of processing and that newlines delimit the end of
single lines comments and */ ends /* block comments. The spec also
indicates that nested comments are not allowed as the inside of a
comment is not parsed and inspected.

Why should comments be made to conform with syntactic character set
restrictions?

David

> - James
>>
>> This is contradicted, of course, by
>>
>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#CHARACTERS_OUTSIDE_VALID_SET
>> which states that shaderSource only accepts the ESSL ASCII subset.
>>
>> Will every author need to use a regex to strip free-form comments out
>> of their shaders before they load them in a browser?
>>
>> Why has WebGL deviated and tightened the ES 2.0 spec on acceptable
>> character sets for shaderSource?
>>
>> Best,
>>
>> David Sheets
>>
>> On Tue, Jan 11, 2011 at 5:23 PM, Vladimir Vukicevic
>> <vladimir@mozilla.com> wrote:
>> > Interesting; in the Firefox version of this check, I just check that the
>> > shader is ASCII before passing it down to ANGLE.  That's not strictly
>> > correct, as the GLSL ES spec defines a subset of ASCII, but I'm not sure if
>> > a more aggressive check is really needed here -- is it?
>> >
>> >    - Vlad
>> >
>> > ----- Original Message -----
>> >> Hello WebGL'ers,
>> >>
>> >> This salutation cannot be used in shader comments in the latest WebKit
>> >> nightly (since r75175 : http://trac.webkit.org/changeset/75175 re
>> >> https://bugs.webkit.org/show_bug.cgi?id=50929 ) due to its use of the
>> >> single quotation mark. Other banned characters include @ and $. This
>> >> behavior is not compliant with the ESSL 1.0.17 spec Sec. 3.5 which
>> >> states:
>> >>
>> >> "If a comment resides entirely within a single line, it is treated
>> >> syntactically as a single space."
>> >>
>> >> While the character check is obviously necessary for setUniform et al
>> >> as strings passed here are parsed according to the ESSL grammar, this
>> >> check shouldn't be used source code strings because the spec does
>> >> allow comments to contain these characters. Important use cases that
>> >> require this include:
>> >> - email addresses in comments
>> >> - CVS escaping ($Id$)
>> >> - as Zhenyao describes in WebKit bug 50929, Apple and Google copyright
>> >> symbols
>> >>
>> >> It should be noted that comments in shaders in the ESSL spec contain
>> >> characters not in the grammar character set. See a unicode not_equals
>> >> character in Sec 4.6.2 and many uses of both ASCII and Unicode
>> >> quotation marks in their example comments.
>> >>
>> >> These character set checks should be done post-lexing not on the raw
>> >> string data. Additionally, these post-lexing checks should emit lex
>> >> location information to let shader authors track down legitimately
>> >> erroneous characters in their source code rather than simply refusing
>> >> to compile with a generic error message.
>> >>
>> >> $Valediction$,
>> >>
>> >> David Sheets
>> >> Ashima Arts
>> >> -----------------------------------------------------------
>> >> You are currently subscribed to public_webgl@khronos.org.
>> >> To unsubscribe, send an email to majordomo@khronos.org with
>> >> the following command in the body of your email:
>> >> unsubscribe public_webgl
>> >> -----------------------------------------------------------
>> >
>>
>> -----------------------------------------------------------
>> You are currently subscribed to public_webgl@khronos.org.
>> To unsubscribe, send an email to majordomo@khronos.org with
>> the following command in the body of your email:
>> unsubscribe public_webgl
>> -----------------------------------------------------------
>>
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------