search

troglobit / editline

A small replacement for GNU readline() for UNIX
https://troglobit.com/projects/editline/
Other
282 stars 58 forks source link

Completion of error handling #14

Closed elfring closed 7 years ago

elfring commented 7 years ago

Would you like to add more error handling for return values from functions like the following?

troglobit commented 7 years ago

The former yes, the latter no, not needed.

Fixed in ea79fe7.

elfring commented 7 years ago

…, the latter no, not needed.

Why? - I find this view questionable.

I suggest to avoid ignorance of return values a bit more. Would you like to detect every error situation as early as possible?

troglobit commented 7 years ago

The latter is checked the next time the function is called.

elfring commented 7 years ago

I find the current error detection and corresponding exception handling still incomplete. How do you think about to improve static source code analysis also for your software?

troglobit commented 7 years ago

Well, that's your opinion, which you're entitled to. From my point of view this is becoming a bit tiresome, your constant nitpicking on every tiny aspect and never submitting any pull requests or patches of your own. I appreciate bug reports, but you have to also know when to stop requesting favors for free, and try to get a feel for when you're taking things a bit too far. As a maintainer it is not my job to fulfill the requests of everyone filing an issue. If you're a user of editline, then grab a shovel and help out, or fork the project if you're dissatisfied with my maintainership. Thank you.

Coverity Scan is already active for this project, a run will be scheduled before the next upcoming release.

elfring commented 7 years ago

…, your constant nitpicking on every tiny aspect

I dare to point further improvement possibilities out.

and never submitting any pull requests or patches of your own.

This view can be appropriate for your software so far. But the situation is different if you look at my contributions in other information systems.

As a maintainer it is not my job to fulfill the requests of everyone filing an issue.

This view is generally appropriate. - There are more options available to change the affected software.

Coverity Scan is already active for this project, …

I am curious if this analysis tool will point similar open issues out which I mentioned here.

troglobit commented 7 years ago

Dude, do you really have to have the last word in everything? I stopped even considering doing more work in the pingfs project because you literally took the fun out of it!

In this particular case, pertaining to this issue, you say " I find this view questionable.", which means you question my judgment. So, let's have a look at that strdup() that's in contention here:

Would one want search_hist() to fail for not managing to (conveniently) save the string I just search for? In my opinion, no. The responsibility of the function is to search the history to return any match of a prior readline() entry. If this function is called again it will have no knowledge of any prior search, due to the strdup() having failed. Which, again in my view, is OK since there are no side effects apart from loss of the last search term.

The whole point of the library is to make it easy to read a line, not to barf on every possible error, and that's the design philosophy I am likely maintain for the duration. You may have another approach to things, and that's fine, but in this project I'm the sole maintainer and don't have to explain every single decision.

I encourage your "more options", like forking, patching or whatnot, let a thousand flowers bloom, as they say. Had we not got off on the wrong foot I might have given you access to my Coverity Scan results.

rofl0r commented 7 years ago

it seems it's not very hard to get off on the wrong foot with you . would you consider being more friendly to your users ? 😁

troglobit commented 7 years ago

@rofl0r So far, in my "career" on GitHub I've had disagreements on design and error handling with two people, and fruitful collaborations with several others. I'm not sure that could be characterized as being unfriendly, but that is for others to decide, I'm not that vain.

What is interesting to note, though, is that a difference of opinion and decision by a maintainer can be so hard to accept for some as the end of a discussion.