The Blue Meanie wrote:
> Heh.  Well, they ship a libsendfile.so, but from what I've seen in the past,
> not all of the functions in it are even implemented, let alone implemented
> correctly.

Incorrectly in which way? sendfile() may not work for certain filesystems
and might not work for large files if it wasn't compiled with large file
support. Gtk-Gnutella disables sendfile() support temporarily the first
time it fails during any session. So even if sendfile() is just a stub
fails with ENOSYS or similar each time, it shouldn't really cause any
problem beyond a single failed upload.

> I agree.  But Sun's Forte has always been pretty picky about stuff.  To the
> point of being a real hassle sometimes.

I wouldn't really blame that on Sun's compiler. GCC has *optionally* a lot
of extra warnings (although it doesn't catch this one at all) but it's
pretty lax by default so that people can get away with broken code. For
a dominant compiler like GCC that's really bad but maybe it's actually
also popular due to this.

> > > Finally, in src/lib/misc.c, at line 722, my compiler seems to have issues 
> > > with
> > > the ': (g_assert_not_reached(), -1)' construct, reporting a "syntax error:
> > > empty declaration" at the "if".
> > 
> > I've fixed this now.
> > 
> Ok.  Honestly, it really didn't look like this needed to be "fixed".  The
> nested ? : ? : layout made perfect sense, and was nice and compact.  I still
> pin this on Forte being too picky.

The problem is that g_assert_not_reached() expands to something like

        if (1) { abort() } else { (void) 0; }

unless you use GCC. An "(" followed by an "if" isn't valid C in my
book. GCC, however, allows "({" and "})" or the like for nested C
code. Maybe it's a ISO C99 feature but I don't think so.

> > There should have been a bugfix release by
> > now but there wasn't because nobody's time for that.
 
> Considering the size of the GTKG codebase, the fact that it offers both a GTK1
> and GTK2 ui, and the fact that the network itself is evolving the way it is, I
> can totally believe this.

That's true regarding adding new features and with respect to debugging
code but I was really just talking about releasing a new version. There
are still unresolved issues in CVS but the current code is much, much more
stable than 0.95 and has some build issues fixed. Considering that 0.94
doesn't work anymore and people had to update makes it worse.

> I tend to fight the urge to report a bug unless I've worked it
> through and can at least offer a decent suggestion on where and why it
> happens, and a fix if at all possible.  Nothing's more useless than a zillion
> "foo crashed on me, can you fix it?" reports, right?

It's well appreciated if you can provide a fix along with a bug report
and I tend(ed) to do so myself. However, often you can safe yourself
a lot of work, if you submit the bug report first. The developers or
someone else reading it might be able to fix it right away, may
inform you that it had been fixed already or just provide some further
information/knowlegde for a workaround.
It's a little embarassing if there are a lot of unresolved bugs but
nobody gets a dime for it anyway and I think it's much better to
know that there is (or might be) a bug than ignoring an issue. I
assume that 99% of all people who run into a bug won't report it and
might even switch to a different application, so every report is
important even if it might turn out to be useless later.

> I do pride myself on
> being able to spot a 32-/64-bit mismatch from a mile away, at least.

Well, too bad. I'm afraid those are all fixed.
 
> Anyway, thanks for the feedback, and I'll try to get moved up to a current
> CVS version soon.  Before I dive into that, is there a requirement for the
> various gnu auto* components to use CVS?

No, you need exactly the same as for a release source tarball - that
means a C compiler, make, sh, sed, awk, GLib, Gtk+, libxml2.

> And since I'm always paranoid about sounding like a whiner, I'll repeat the
> kudos to all involved.

Have you ever read Eric Raymond's FAQ about writing bug reports? IMHO,
he goes much too far in it (and I can't stand when people try to speak
in the name of others anyways). If there's a bug, issue or whatever just
report it. There's absolutely nothing impolite, insulting etc. about
it. It's quite contrary as explained above. Some people tend to add some
insulting rants to reports which isn't really nice - but can be
entertaining nonetheless. ;)

-- 
Christian

Attachment: pgptvaZr4U7JN.pgp
Description: PGP signature

Reply via email to