Re: 64-bit fun with cache.c

On Sat, Jan 24, 2009 at 6:44 AM, Laurent Bercot <[email protected]> wrote:
>> If it's not too ugly, I'm not going to worry about it.
>
>  Well, I am going to worry about it.
>  You sound like a child who's found a new toy to play with, and that
> toy happens to be djbdns. As long as you're hacking it on your own
> and experimenting on your own private machines, more power to you,
> that's what free software is for. But as soon as you're packaging
> and distributing the results of your experiments, you have a
> responsibility: to ensure the quality of what you're distributing.

I named my package zinq-djbdns.  I started with version 0.01.  Let me
quote the README file for you:

WARNING! DANGER!

PROCEED WITH CAUTION!

This is not stock djbware.  It has been altered in ways that Dan would probably
not approve of.  See CHANGES and http://zinq.sourceforge.net for details.

DISCLAIMER:  This release might eat your data.  It might even eat your lunch.
No warranty.  Use at your own risk.

To your knowledge, has anybody mistaken zinq-djbns for djbns?  Do you
have a bug report to file?  Just because I post a diff to a mailing
list with questions attached doesn't mean I'm going to commit the
changes to source control and ship them with no testing.  I am aware
of Dan's test suite.  He has a test that exercises the code in
cache.c, but not to the extent I consider necessary before shipping a
64-bit cache.c.  I would actually want to push the cache to and past
the 4G point and see that it was still functioning correctly.

I do feel like a kid on Christmas morning with a pile of presents to
open.  This is the most fun coding that I've had in years, and I'm
just getting started.

>  You started with autoconfizing a working build system for no other
> reason than "I want to be able to build djbdns the same way as other
> packages". You're continuing with "I can use uint64 everywhere, the
> compiler will optimize it for me", when I had just given you the
> answer to a question you asked, which was "how can I detect native
> 64-bit platforms ?"

Do you want to read my message again?  Where do you see "how can I
detect native 64-bit platforms?"  I stated: "I don't want to screw
around with trying to detect whether the build platform is 32-bit or
64-bit."  I did not say "I can use uint64 everywhere, the compiler
will optimize it for me".  I said "I can just declare them uint64 and
let autoconf and the compiler sort it all out."  I later said "I may
just compile a test program and disassemble it and see what the
compiler ends up generating."  Later still, I said "The compiler might
optimize it all away.  Any insight appreciated."  Do you have a clue
what kind of machine code any particular compiler would generate in
this case?  If so, I'd love to hear about it.  If not, please go
misread somebody else's messages for a while.

>  I know it's not what you want to hear, and I'm sorry to be harsh,
> but you sound careless - way more careless than I'm comfortable with
> where djbware is concerned. djbware is quality software, it needs
> to be adopted more widely, but it has suffered from bad publicity
> for a long time, and most people are reluctant to use it. The main
> advantage it has is *quality of code* : djbdns is probably the
> *least* buggy DNS software suite that was ever written. And now that
> it is in the public domain, it needs to remain that way.

Hey, if you don't like my methods, feel free to ship your own package.
 Really, please, right now, go get netdjbdns 1.06 ready and ship it.
Feel free to attribute all sorts of things I didn't actually say to me
in the README.

By the way, you do realize, don't you, that all you're accomplishing
by arguing with me is an increase in my pagerank?

>  Your approach sounds likely to introduce bugs into the code. This
> is not a good thing for djbdns' reputation, and ultimately, this is
> not a good thing for the users either. Please don't do this. Please
> be more careful with changes you make to code you're going to
> package and distribute.

Why don't you go download my package, find a bug, and file a report?
Then you can accuse me of *actually* introducing bugs into the code
instead of merely *likely* introducing bugs into the code.  You know
what's not good for djbdns' reputation?  Not compiling out of the box
on a modern Linux distribution without patches.  I don't care who's
right and who's wrong about how errno should be defined.  It should
compile as shipped.  You don't like patches to tweak the source?
Fine, when you ship netdjbdns-1.06, include a tweaked Makefile that
will generate a conf-cc with '--include/usr/include/errno.h' on linux
boxes.  While you're at it, update the root server list.  That 'aint
helping ye olde reputation, either.  You might want to fix the
SERVFAIL and SIGPIPE issues, too.  Whoops, did I just include fixes
for two bugs in zinq-djbdns?  Silly me!  I'm not living down to your
expectations.  Sorry!  I'll try extra hard to break something in the
next release just for you.

>  We don't need more GNU-quality software.

I know you didn't intend it as such, but I actually consider this a
compliment.  Thank you very much!