[LLVMdev] raw_ostream behavior

[Shankar Easwaran]

Hi Dan,

The other messages, need to go to stdout as well. Using stderr to output 
for a switch like --verbose is wrong in my opinion.

On 8/14/2013 4:44 PM, Dan Gohman wrote:
> Would it be appropriate for lld's other output to go to standard error
> instead of standard output, since standard output may be used for YAML
> output?
>
> Dan
>
> On Wed, Aug 14, 2013 at 12:53 PM, Shankar Easwaran
> <shankare at codeaurora.org>wrote:
>
>> Hi Dan,
>>
>> lld takes a -emit-yaml option, which emits the intermediate
>> representation(atoms) in YAML form.
>>
>> By default output goes to stdout, the user can control it by using the -o
>> option too.
>>
>> The way its handled is, similiar to this piece of pseudo-code
>>
>> if (dash_o_option)
>>      outputFile = dash_o_option->value()
>> else
>>     outputFile = "-"
>>
>> When lld tries to mix things that go to stdout using llvm::outs() and
>> -emit-yaml, it starts to get this error.
>>
>> If there is a restriction like this, possibly it has to be mentioned
>> somewhere for usecases (or) raw_fd_ostream should not be accepting a '-' in
>> the argument.
>>
>> What do you think ?
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>>
>> On 8/14/2013 2:02 PM, Dan Gohman wrote:
>>
>>> The high-level answer is that library code shouldn't hardcode output
>>> paths,
>>> including "-" and including using llvm::outs(). Library code should (in
>>> general) instead accept an ostream in its API and write to wherever it is
>>> being asked to write. If this is followed, the only place in any program
>>> using llvm::outs() is code which is not part of a "library" -- i.e. it is
>>> the "main" code, and it should only do so if it is a program which doesn't
>>> open file names which could be "-".
>>>
>>> Do you have a use-case where this restriction is too restrictive?
>>>
>>> As a random aside, a more aggressive answer could be that "-" is a kind of
>>> hack, and that it would be a better approach to use /dev/stdout and
>>> /dev/stdin instead of "-", because they wouldn't require special-case
>>> logic. Unfortunately, this may not be sufficiently portable.
>>>
>>> Dan
>>>
>>>
>>> On Wed, Aug 14, 2013 at 8:28 AM, Shankar Easwaran
>>> <shankare at codeaurora.org>**wrote:
>>>
>>>   Hi,
>>>> When I run the below example, it results in :-
>>>>
>>>> hello
>>>> world
>>>> LLVM ERROR: IO failure on output stream.
>>>>
>>>> Testcase :-
>>>>
>>>> #include <llvm/Support/raw_ostream.h>
>>>>
>>>> int fn() {
>>>>     std::string errorInfo;
>>>>     llvm::raw_fd_ostream out("-", errorInfo);
>>>>     out << "world\n";
>>>>     return 0;
>>>> }
>>>> int main(int argc, char **argv) {
>>>>     llvm::outs() << "hello\n";
>>>>     fn();
>>>>     return 0;
>>>> }
>>>>
>>>> I tried to fix this by making llvm::outs(), not close the stdout
>>>> descriptor, but I think its wrong. Recommendations ?
>>>>
>>>> Thanks
>>>>
>>>> Shankar Easwaran
>>>>
>>>> --
>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>>> by the Linux Foundation
>>>>
>>>>
>>>>
>>>> ______________________________****_________________
>>>>
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/****mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev>
>>>> <http:**//lists.cs.uiuc.edu/mailman/**listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation