2) And how is it cscope's fault if they expect something
that never matched cscope's actual behaviour?
3) Even if that's the case, not using postmsg() would be
precisely the wrong approach to fixing this. If postmsg()
doesn't do its job, change postmsg().
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I should have given some more details.
Cscope has a posterr() function, which is usually used to
report errors. It does so correctly with the line-based
interface (used by front-ends such as KScope), by sending
errors to stderr.
postmsg(), on the other hand, sends output to stdout. I
believe that using stderr for errors is better practice
since it allows the other end to easily distinguish errors
from normal output.
As an example, please refer to command.c:893. I believe this
error should have been reported using posterr().
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=27517
1) Please specify: which front-ends are those?
2) And how is it cscope's fault if they expect something
that never matched cscope's actual behaviour?
3) Even if that's the case, not using postmsg() would be
precisely the wrong approach to fixing this. If postmsg()
doesn't do its job, change postmsg().
Logged In: YES
user_id=378741
Sorry, I should have given some more details.
Cscope has a posterr() function, which is usually used to
report errors. It does so correctly with the line-based
interface (used by front-ends such as KScope), by sending
errors to stderr.
postmsg(), on the other hand, sends output to stdout. I
believe that using stderr for errors is better practice
since it allows the other end to easily distinguish errors
from normal output.
As an example, please refer to command.c:893. I believe this
error should have been reported using posterr().