[CLI] Different source hashes when source is passed via standard input and via command line parameter #11553
Comments
|
Do we need the processing? |
|
Reading the source, I cannot imagine this being intentional. |
|
I don't think we need it. It looked like intentional to me because I can't see why else one would read a file line by line but still return the content. The only reason I can think of is to replace the line endings. |
|
I think this is because it is the most convenient way to read a file. |
|
Can you assign this to me? I can try to tackle this tomorrow and report back. |
|
@TerranCivilian You might want to start by looking at the function that reads data from standard input: solidity/libsolutil/CommonIO.cpp Lines 70 to 82 in cbf1c3a |
|
Thanks for the excellent writeup. After many hours of research and benchmarking, I believe I've produced an optimal solution (as seen here #11584). |
|
Still working on this, mostly on weekends. Hope to wrap it up this weekend. |
Description
The content of the file passed to standard input does not pass through unmodified and its content hash stored in metadata (note: I do not mean the metadata hash itself) is different than when the file name is given as an argument.
The problem is caused by our function for reading standard input, which replaces all newlines with
\nand also adds a newline after the last line, even if originally there wasn't one.In practice the consequences of this are probably minor because even if the source hashes end up being the same, metadata won't be - due to different file names (unless the file is called
<stdin>which is unlikely). Still, I think that this behavior is unexpected by users and should be changed. It looks intentional though and might be a workaround for something so we should discuss it first.Environment
Steps to Reproduce
sourceskey from metadata output:cat contract.sol | solc - --metadatasourceskey from metadata output:The text was updated successfully, but these errors were encountered: