On Aug 6, 2013, at 2:32 AM, Joerg Schilling <[email protected]> wrote:
> Lionel Cons <[email protected]> wrote: > >>> When the code was provided for a review, I took a quick look at it and >>> discovered 7 (IIRC) bugs within 10 minutes. So I send a short list with the >>> bugs to this mailing list. Garret's answer to this short review was not to >>> ask >>> for more details (as people would expect) but to claim that there were no >>> bugs... >> >> Joerg, would you mind helping us, please? Could you send a shell >> script (Bourne or otherwise) which shows each bug with a single test, > > If you asked 33 months ago, there was no problem doing that. > > Now there is a working implementation at: > > > http://hg.berlios.de/repos/schillix-on/file/2d4c6551d3c4/usr/src/cmd/hdump > > and another implementation in Illumos that failed to pass the code review. It passed code review. You complained that there were bugs, but when we *asked* you what those problems were, you failed to provide any actionable feedback. You were completely focused on getting us to use your own program, which *at the time* didn't perform as a stand-in for od. Rather than work with me constructively, you gave only negative non-actionable feedback. And ran off to modify your hexdump program instead of giving me the feedback about what the problematic behaviors were. od has been working fine for many people for a while now. We're happy to fix bugs. File them properly. Right now I'm not aware of any open bugs against od. > > I don't like to waste any more time on that broken implementation (note that > Garret made it very obvious that there is no will for a fix). > > I currently only remember that there have been problems with printing long > doubles, My od behaves the same way as Sun od with -F. Both fail to align columns with -F. I chose to be bug compatible with Sun's in my first implementation. I'm happy to consider whether this behavior should be changed or improved, but that needs to be a conscious decision made by more than just you or me. In the absence of any other guidance, I chose to behave exactly as the Sun closed source implementation. > printing things correctly in columns as documented in the POSIX Again, I chose to follow the existing Sun behavior, and as far as I am aware my version of od behaves as close to Sun's as possible. The possible exception here is that I think I chose to follow XPG4 when implementing -c. (I.e. -c behaves pretty much like -C.) This was discussed at length on the list I believe. > standard, that there was absolutely no support for the SVID-3 behavior and > that What is the shortcoming here? I'm not aware of any other than the -c behavior I already mentioned (which is trivially worked around by putting LC_ALL=C in your environment.) > there have been incorrect UTF-8 character prints for unaligned/partial chars. I don't think this is a problem… at least I don't see any difference in behaviors between my implementation and Sun's, and the behavior seems to be what is documented. If you have a test case showing the defect, I'd like to see it. > > But this is OpenSource; the easiest way to get a correctly working od for > Illumos is to use the existing working implementation from SchilliX-ON. And *this* is what you really want. You are trying to put holes in another program (one that was purpose written for od *before* you had od support in your hexdump program.) > Given > the fact that the od in Illumos did not pass the code review, it should be an It did pass code review. You never found any problems during code review. You gave some negative feedback that amounted to "it's broken, please instead use this program that I just wrote to perform this function." In fact, I seem to recall testing your program and finding several bugs as well. Unlike you, I gave actual constructive feedback detailing the precise problems. Also, I'm not aware that hexdump has ever undergone *any* code review. > easy task to do the replacement. No. First you need to prove that there is an actual deficiency in od and that replacing the current implementation is some how easier for illumos to do than to fix the defect. So far you've done neither. - Garrett ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
