Il 12 marzo 2012 22:13, Józef Kucia joseph.kucia@gmail.com ha scritto:
Hi,
I'm writing because I found a bug in asm shader preprocessor in Wine and I'm not sure what's the best way to fix it.
The D3DPreprocess function is an universal shader preprocess for HLSL and asm shaders. In fact, it's C-like language preprocessor and it doesn't understand assembler style comments (comments from ';' to the end of line). The fact that it doesn't understand these comments is a root of whole problem. Valid asm shaders can contain single or double quotation characters in assembler style comments, and these quotation characters will be treated as a beginning of quoted string constants while preprocessing.
The Wine's implementation of D3DPreprocess behaves differently than Windows implementation in respect to strings passing the end of line. Generally, strings passing the end of line are an error in C, but they can result in a correct asm shader when contained in a assembler style comment. D3DPreprocess on Windows works fine for shaders which contains single or double quotation marks. It only issues an error in case of unmatched double quotation mark, but returns D3D_OK anyway. In Wine situation is different, wpp tries to find a matching quotation mark to the end of file, while shader preprocessor on Windows gives up on parsing a string when it gets a first newline character. The result of wpp's behavior is a truncated output and an error returned from D3DPreprocess.
I wonder if it's fine to change wpp behavior for strings passing the end of line to mimic the behavior observed on Windows. Perhaps, strings passing the end of line could be treated as an error by default. Whereas D3DCompiler would activate an option to treat such strings as a warning.
Thanks, Józef Kucia
That is bug http://bugs.winehq.org/show_bug.cgi?id=24614. My shot at it was http://www.winehq.org/pipermail/wine-patches/2011-February/098609.html. You can see that my approach was essentially what you are suggesting. Still, that's not a very nice thing to do probably (and indeed my patch wasn't accepted at the time ;). Rereading it now, I notice that the patch also contains some wpp cleanup which should have been in separate patches, but I don't think that it was the reason of the reject... Dan tried a slightly different solution a while later, but still no dice.
I'm unsure how a "correct" solution would be. The tests included in my patch essentially show that this asm-style comments thing is a PITA even for native d3dcompiler, so probably there can't be a really clean and nice solution. Also, some ad-hoc changes to wpp are needed anyway and have to "kick in" only when wpp is used by d3dcompiler, without affecting the other users.
I'll think about it again as soon as I'll get some time. If you get any idea, I'd like to hear it (or, writing a good fix would be even better ...)