[illumos-Developer] webrev: reimplementation of od

[Aram Hăvărneanu]

On Mon, Oct 18, 2010 at 10:13 PM, Joerg Schilling
<Joerg.Schilling at fokus.fraunhofer.de> wrote:
> I do not expect you to "see" the problem like I did within the first 2 minutes
> and without compiling.

Cut the vanity crap please.

> I however expect people who like to integrate code to do
> tests. If you did test, you did know that the code does not work with large
> files as expected.

The above phrase serves no purpose as it doesn't help people that work
on this (as opposed to people that just like to whine about things) in
any way. The only purpose of the above mentioned phrase is to increase
the entropy on the mailing list.

>> > -   Uses hidden intefaces not intended for the public
>>
>> You must mean my of *64.  I'm not sure if they were intended for public
>> consumption or not, but I had a specific reason in choosing this
>> approach.  I wanted to be guaranteed that the code was 64-bit clean, and
>> not dependent on compiler options, specifically my use of strtoll() in
>> argument parsing was a concern.
>>
>> At the end of the day, those interfaces are guaranteed to be safe,
>> because they get baked into binaries compiled with -D_LARGEFILE_SOURCE,
>> so I'm not worried about my explicit usage, and use of internal
>> interfaces is always safe for a program targetting ON anyway.
>>
>> However, if you're truly offended by this usage, I'll convert to use
>> off_t and -D_LARGEFILE_SOURCE.
>
> The interface you are using is not an official interface

It is an ON program, stability attributes apply only to consumers of
ON, e.g. third parties that write Solaris software. Surely stability
attributes have a meaning to ON programs, we shouldn't use volatile
interfaces for the sake of doing so if there's no reason for this, but
those interfaces can hardly be called volatile in this case AND I'm
with Garret on this. I think we should do most of the stuff in code
where we can instead of relying on outside meta-information, like
pre-processor defines. However, this is my *personal opinion* and if
other people that, umh, actually *DO STUFF* are of a different opinion
then we will do it the other way.

> and the way your
> program was written, it only gets a partial large file aware system interface.
> This is not what we like to have.

The above phrase mentions no specific issues serving no purpose as it
doesn't help people that work on this (as opposed to people that just
like to whine about things) in any way. The only purpose of the above
mentioned phrase is to increase the entropy on the mailing list.

> Your code uses a mix of types that will not be in a cleanly written program.

The above phrase mentions no specific issues serving no purpose as it
doesn't help people that work on this (as opposed to people that just
like to whine about things) in any way. The only purpose of the above
mentioned phrase is to increase the entropy on the mailing list.

> See "man lfcompile" and "man getconf" for more information on how to correctly
> write and compile large file correct software.

Maybe good as a general guideline, but in this specific scenario the
above phrase mentions no specific issues serving no purpose as it
doesn't help people that work on this (as opposed to people that just
like to whine about things) in any way. The only purpose of the above
mentioned phrase is to increase the entropy on the mailing list.

> You implemented only the easy to understand and easy to implement part of
> od(1), you however miss those parts that are hard to understand and to code
> correctly.

The above phrase mentions no specific issues serving no purpose as it
doesn't help people that work on this (as opposed to people that just
like to whine about things) in any way. The only purpose of the above
mentioned phrase is to increase the entropy on the mailing list.

> I would guess that it is easier to enhance hdump(1) with the new
> POSIX features than to add support for the non-obvious funtionality of od(1)
> to your program.

I'd suggest you either fix this implementation of od(1) or write one
yourself based on hdump(1) and submit it for review instead of whining
on the mailing list that we don't integrate your code.

> This could have been noticed from testing.

The point of reviews is to review stuff. The fact that you spotted an
issue with the code above mean web reviews *are working*. Thanks for
the feedback, this is useful stuff as opposed to the entropy noise
that help no one.

> As this happened with _every_ test I did run, I expect this problem to be
> easy to see.

Even if true, the above phrase mentions no specific issues serving no
purpose as it doesn't help people that work on this (as opposed to
people that just like to whine about things) in any way. The only
purpose of the above mentioned phrase is to increase the entropy on
the mailing list.

> BTW: If I compare the default od(1) performance (no options) from Sun's "od"
> with "hdump" and with your "od -o" using a mostly nulled file, I get the
> following results:

Comparing different programs like hdump(1) and od(1) serves no purpose.

>> > How about enhancing hdump(1) with the od(1) interface?

How about doing it yourself, posting it for review and then talk? At
the moment we have an od(1) that seems to work well, albeit not
perfectly. You suggest to *start from scratch* just to use your code?
Hahaha.

> Your problem seems to be that you don't talk with other people before starting
> to work on a problem. Talking with other people can avoid to reinvent the wheel.

Oh man, do stuff, then talk. Not the other way around.

-- 
Aram Hăvărneanu