<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>181309</bug_id>
          
          <creation_ts>2018-01-04 14:54:38 -0800</creation_ts>
          <short_desc>Sandbox preprocessing should handle C++ comments</short_desc>
          <delta_ts>2018-03-31 23:03:08 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebKit2</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>DUPLICATE</resolution>
          <dup_id>184166</dup_id>
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar</keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Brent Fulgham">bfulgham</reporter>
          <assigned_to name="Brent Fulgham">bfulgham</assigned_to>
          <cc>achristensen</cc>
    
    <cc>ap</cc>
    
    <cc>bfulgham</cc>
    
    <cc>darin</cc>
    
    <cc>ggaren</cc>
    
    <cc>webkit-bug-importer</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1385948</commentid>
    <comment_count>0</comment_count>
    <who name="Brent Fulgham">bfulgham</who>
    <bug_when>2018-01-04 14:54:38 -0800</bug_when>
    <thetext>The text preprocessing rules in WebKit&apos;s DerivedSources.make is now only used for processing our sandbox profiles. Sometimes the headers and availability macros included on macOS and iOS SDK&apos;s have spurious C++-style comments in them, which are not stripped out during preprocessing since we were telling clang to use C89 rules for preprocessing.

Instead, we should switch to C99 so that C++-style comments will get properly ignored, and we won&apos;t confuse the Sandbox library when it tries the read the finished file.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1385949</commentid>
    <comment_count>1</comment_count>
    <who name="Radar WebKit Bug Importer">webkit-bug-importer</who>
    <bug_when>2018-01-04 14:59:33 -0800</bug_when>
    <thetext>&lt;rdar://problem/36306874&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1385950</commentid>
    <comment_count>2</comment_count>
      <attachid>330490</attachid>
    <who name="Brent Fulgham">bfulgham</who>
    <bug_when>2018-01-04 15:02:03 -0800</bug_when>
    <thetext>Created attachment 330490
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1385987</commentid>
    <comment_count>3</comment_count>
      <attachid>330490</attachid>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2018-01-04 16:16:54 -0800</bug_when>
    <thetext>Comment on attachment 330490
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=330490&amp;action=review

&gt; Source/WebKit/ChangeLog:9
&gt; +        Switch to C99 rules for preprocessing our sandbox profiles. No other code uses the TEXT_PREPROCESSOR_FLAGS

Can you diff processed profiles? This seems likely to break all comments with &quot;rdar://&quot; in them. Theoretically, it can break actual rules if they have double slashes, but we don&apos;t have any like that now.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1385990</commentid>
    <comment_count>4</comment_count>
      <attachid>330490</attachid>
    <who name="Brent Fulgham">bfulgham</who>
    <bug_when>2018-01-04 16:25:27 -0800</bug_when>
    <thetext>Comment on attachment 330490
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=330490&amp;action=review

&gt;&gt; Source/WebKit/ChangeLog:9
&gt;&gt; +        Switch to C99 rules for preprocessing our sandbox profiles. No other code uses the TEXT_PREPROCESSOR_FLAGS
&gt; 
&gt; Can you diff processed profiles? This seems likely to break all comments with &quot;rdar://&quot; in them. Theoretically, it can break actual rules if they have double slashes, but we don&apos;t have any like that now.

Yes -- it definitely cuts off everything after the &quot;//&quot; in the comment, so maybe we don&apos;t want to do that.

We should probably create a WebKit-specific filter program that does exactly what we want.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1386606</commentid>
    <comment_count>5</comment_count>
      <attachid>330490</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2018-01-07 22:56:44 -0800</bug_when>
    <thetext>Comment on attachment 330490
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=330490&amp;action=review

&gt;&gt;&gt; Source/WebKit/ChangeLog:9
&gt;&gt;&gt; +        Switch to C99 rules for preprocessing our sandbox profiles. No other code uses the TEXT_PREPROCESSOR_FLAGS
&gt;&gt; 
&gt;&gt; Can you diff processed profiles? This seems likely to break all comments with &quot;rdar://&quot; in them. Theoretically, it can break actual rules if they have double slashes, but we don&apos;t have any like that now.
&gt; 
&gt; Yes -- it definitely cuts off everything after the &quot;//&quot; in the comment, so maybe we don&apos;t want to do that.
&gt; 
&gt; We should probably create a WebKit-specific filter program that does exactly what we want.

No, I don’t think this will break /* */ comments with // inside them. Those work fine in C++; why wouldn’t clang handle that properly?

Actual rules with double slashes is something different, though. Maybe that’s important?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1386764</commentid>
    <comment_count>6</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2018-01-08 09:35:04 -0800</bug_when>
    <thetext>The comments in .sb.in files are of this form:

    ; &quot;com.apple.coremedia.endpointpicker.xpc&quot; can be removed when &lt;rdar://problem/30081582&gt; is resolved.

And with this patch, the built .sb file has lines like this:

    ; &quot;com.apple.coremedia.endpointpicker.xpc&quot; can be removed when &lt;rdar:

I don&apos;t think that it&apos;s particularly important to preserve comments in sandbox profiles, so maybe the solution is to switch from &quot;;&quot; to &quot;//&quot; for comments. The only downside will be that comments will be inconsistent between processed and non-processed sandbox profile sources (e.g. Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in vs. Source/WebKit/Resources/SandboxProfiles/ios/com.apple.WebKit.Networking.sb).

And yes, rules with double slashes are probably not important. If one is ever introduced, this will almost certainly break profile compilation, so bots will quickly tell us about the problem.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1410943</commentid>
    <comment_count>7</comment_count>
    <who name="Alexey Proskuryakov">ap</who>
    <bug_when>2018-03-31 23:03:08 -0700</bug_when>
    <thetext>

*** This bug has been marked as a duplicate of bug 184166 ***</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>330490</attachid>
            <date>2018-01-04 15:02:03 -0800</date>
            <delta_ts>2018-01-04 16:27:04 -0800</delta_ts>
            <desc>Patch</desc>
            <filename>bug-181309-20180104150202.patch</filename>
            <type>text/plain</type>
            <size>1638</size>
            <attacher name="Brent Fulgham">bfulgham</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9XZWJL
aXQvQ2hhbmdlTG9nCShyZXZpc2lvbiAyMjY0MjQpCisrKyBTb3VyY2UvV2ViS2l0L0NoYW5nZUxv
Zwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBACisyMDE4LTAxLTA0ICBCcmVudCBGdWxn
aGFtICA8YmZ1bGdoYW1AYXBwbGUuY29tPgorCisgICAgICAgIFNhbmRib3ggcHJlcHJvY2Vzc2lu
ZyBzaG91bGQgaGFuZGxlIEMrKyBjb21tZW50cworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0
Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTgxMzA5CisgICAgICAgIDxyZGFyOi8vcHJvYmxlbS8zNjMw
Njg3ND4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBT
d2l0Y2ggdG8gQzk5IHJ1bGVzIGZvciBwcmVwcm9jZXNzaW5nIG91ciBzYW5kYm94IHByb2ZpbGVz
LiBObyBvdGhlciBjb2RlIHVzZXMgdGhlIFRFWFRfUFJFUFJPQ0VTU09SX0ZMQUdTCisgICAgICAg
IG1hY3JvIGFueW1vcmUsIHNvIGdldCByaWQgb2YgZmFsbGJhY2sgY29kZSBmb3IgYnVpbGRpbmcg
d2l0aCA1KyB5ZWFyLW9sZCBjbGFuZy4KKworICAgICAgICAqIERlcml2ZWRTb3VyY2VzLm1ha2U6
CisKIDIwMTgtMDEtMDQgIFRpbSBIb3J0b24gIDx0aW1vdGh5X2hvcnRvbkBhcHBsZS5jb20+CiAK
ICAgICAgICAgV0tXZWJWaWV3IGxvc2VzIG1pbmltdW0gbGF5b3V0IHNpemUgb3ZlcnJpZGVzIHRo
YXQgaGFwcGVuIHdoaWxlIHRoZSBwcm9jZXNzIGlzIHRlcm1pbmF0ZWQKSW5kZXg6IFNvdXJjZS9X
ZWJLaXQvRGVyaXZlZFNvdXJjZXMubWFrZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViS2l0L0Rl
cml2ZWRTb3VyY2VzLm1ha2UJKHJldmlzaW9uIDIyNjM3MykKKysrIFNvdXJjZS9XZWJLaXQvRGVy
aXZlZFNvdXJjZXMubWFrZQkod29ya2luZyBjb3B5KQpAQCAtMjEzLDE0ICsyMTMsNyBAQCBhbGwg
OiBcCiAJQHB5dGhvbiAkKFdlYktpdDIpL1NjcmlwdHMvZ2VuZXJhdGUtbWVzc2FnZXMtaGVhZGVy
LnB5ICQ8ID4gJEAKIAogCi0jIFNvbWUgdmVyc2lvbnMgb2YgY2xhbmcgaW5jb3JyZWN0bHkgc3Ry
aXAgb3V0IC8vIGNvbW1lbnRzIGluIGM4OSBjb2RlLgotIyBVc2UgLXRyYWRpdGlvbmFsIGFzIGEg
d29ya2Fyb3VuZCwgYnV0IG9ubHkgd2hlbiBuZWVkZWQgc2luY2UgdGhhdCBjYXVzZXMKLSMgb3Ro
ZXIgcHJvYmxlbXMgd2l0aCBsYXRlciB2ZXJzaW9ucyBvZiBjbGFuZy4KLWlmZXEgKCQoc2hlbGwg
ZWNobyAnLy94JyB8ICQoQ0MpIC1FIC1QIC14IGMgLXN0ZD1jODkgLSB8IGdyZXAgeCksKQotVEVY
VF9QUkVQUk9DRVNTT1JfRkxBR1M9LUUgLVAgLXggYyAtdHJhZGl0aW9uYWwgLXcKLWVsc2UKLVRF
WFRfUFJFUFJPQ0VTU09SX0ZMQUdTPS1FIC1QIC14IGMgLXN0ZD1jODkgLXcKLWVuZGlmCitURVhU
X1BSRVBST0NFU1NPUl9GTEFHUz0tRSAtUCAteCBjIC1zdGQ9Yzk5IC13CiAKIGlmbmVxICgkKFNE
S1JPT1QpLCkKIAlTREtfRkxBR1M9LWlzeXNyb290ICQoU0RLUk9PVCkK
</data>

          </attachment>
      

    </bug>

</bugzilla>