Completion of error handling about editline HOT 9 CLOSED

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.

from editline.

The former yes, the latter no, not needed.

Fixed in ea79fe7.

from editline.

…, 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?

from editline.

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

from editline.

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?

from editline.

…, 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.

from editline.

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:

• it's for saving the i-search string, so that a subsequent search may reuse it
• the function itself search the history, returning a match or not

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.

from editline.

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 ? 😁

from editline.

@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.

from editline.