-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
give the possibility to redirect the stderr to nullptr #131
Comments
For reference: Line 145 in c2ef220
What is the reason for that code existing? Limits usefulness of qhull for wrapping tools. Is the intended way to go about this for the user to pass their own file pointer and direct it into the void? |
Qhull is designed for error handling. All computations are done in floating point arithmetic which is inherently imprecise. The geometric computations are used to make topological decisions. All kinds of errors can occur. In short it is important to track and manage errors. Qhull offers multiple options for output (see user_r.h an user_r.c User definable options) All output goes through qh_fprintf with a location ID. You can define your own qh_fprintf in userprintf_r.c and use the results as needed. Option 'Ta' annotates output with the location ID. Rewrite qh_printhelp* in user_r.c (the long descriptive error messages), These messages are shortened if 'qh_QUICKhelp' is set in user_r..h. In addition, qh_QUICKhelp reduces output elsewhere. Rewrite qh_errexit and qh_errprint in user_r.c to define your own error handling. |
In the actual implementation the stderr is not redirectable to nullptr because in
user.c
qh_new_qhull
line 145
if(!errfile){
errfile= stderr;
}
and
same in user_r.c
line 133
if(!errfile){
errfile= stderr;
}
I think that is not correct.
As a matter of facts I am using qhull to implement a segmentation so I have to apply subsequently many times also to small sets where I happen to get often errors by qhull and so my stderr is flood with unwanted verbouse errors, while I just would like to catch the exit error code to handle it accordingly
But in general the user should be able to redirect stderr to null as it happens standard with most tools
If I delete these lines of code
//if(!errfile){
// errfile= stderr;
//}
and I set errfile=nullptr
then I get other errors by the called error log output functions
I wonder if it is sufficient to add code like this
if (!fp)
return;
at the beginning of all error log output functions (which seem to be many... are there a few that collect all of it?)
The text was updated successfully, but these errors were encountered: