<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 24, 2019, 7:39 PM Ben Boeckel &lt;<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I have GCC writing out JSON-like syntax right now. It isn&#39;t 100% valid<br>
since it isn&#39;t UTF-8, but I don&#39;t want *that* in these files either.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It seems reasonable to have non-ascii in user-provided data fields. We should figure out how to handle the case where the user&#39;s path is invalid utf8, like ok linux where it can be a random bag-o-byte or on UCS2 platforms that allow mismatched surrogates. If the compiledb format handles these cases, we should probably just do whatever they do.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, you can&#39;t know until you actually compile the BMI whether it has<br>
changed or not. The best we can ask for is &quot;only update if contents are<br>
unchanged&quot;. Getting that for .o files would be nice as well. Ninja can<br>
then optimize no-change compilations via `restat`.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I didn&#39;t just mean for the scan phase. The BMI can change in ways that don&#39;t require the downstream stuff to be recompiled, eg a comment string was changed on a line of source included only for better error reporting. Similarly, I could see that something like that happening with the .o and split-dwarf / osx-style unsplit-split-dwarf.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; And for the love of $diety, don&#39;t put any locale- sensitive strings in this<br>
&gt; metadata!<br>
<br>
I&#39;d rather have it just be &quot;a series of bytes that is a valid lookup on<br>
the filesystem&quot;. The `\` and `&quot;` characters are escaped using `\` for<br>
obvious reasons. Maybe we do it for control characters as well. Is that<br>
good enough for a specification?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think I made my point poorly, and was misinterpreted. I was just making a joke about /showIncludes. The equivalent behavior would be to make the field names in the json file match the user&#39;s language. I hope no vender is mean enough to actually do that! Obviously users need to be able to use their language in their files and paths. I&#39;m not suggesting we limit that in any way, just that the field names are predictable.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>