Hi everyone. That was a busy week there. Y'all would just wait till
the ONE week I'm out of the country to start makin' noise, wouldn't ya?
It's getting late here and I'm exhausted from the flight and two missed
connections (long story on the first one. Suffice to say, I saw parts
of Frankfurt most locals never see), so I'll keep this to short
summaries for the moment...
Bug#1588093 / libssh2_poll_channel_read()
* Havn't looked into it, but I've got the message flagged for the
Crash during key exchange
* Agreed, why have failure codes if they don't get used. The proposed
patches look good to me.
All your mem are belong to us
* I've actually got defines in there for packet sizes, but for some
reason they're only being used in relation to compression. Someone will
need to add that in...
* I agree that LIBSSH2_ALLOC() should have a sanity check for
allocations. I can't think of a spot where more than 64k is ever used,
though might make this 256kb just to be tolerant.
* Yes, those usually are religious issues.
* I don't see anything wrong with placing hard-wraps at 80 chars and it
probably would add much to readability in most cases. Let's make it a
soft rule though, there are times when a couple extra over is better
than a forced split.
* The only rules I'm really particular about are:
* Tab-indents, not spaces.
* Bracing, even for one-line if conditions
* Commenting commenting commenting :)
* Yes, I know I've broken all three of these rules at least once :)
Moving private include files
* Is there any particular reason this is desired? I'm not inherently
against it, but I don't see an impetus for it.
* For the record, SF project admins don't have direct access to CVS so I
couldn't do this if I wanted to. Well, okay I could, but only because
Sourceforge NetOps is across the street and I've known the guys who run
it since forever :)
OpenSSL and pkg-config
* Looks okay to me. I'm no expert on pkg-config and will defer to y'all
on that one.
* Yeah, I know treating long as 32bit is an abuse, but I think I've
taken reasonable steps to ensure that overflows aren't problematic.
* In theory someone might try building on a 16bit device (some embedded
app), and this is reason enough to properly detect a true 32bit type,
but I won't lose much sleep over it.
* In the win32 case, that typedef is reliable, don't recall the darwin
case... Did someone else put that in?
* The win32 build system is something someone else threw in as I have
neither the experience or the motivation to focus on DLL builds. If
someone wants to make this area shine, you'd be a godsend.
* Sure, go for it. In the beginning a hand-crafted Makefile.in was
simpler to get things going, but there are a few source files and the
file is getting a bit unruly. Using a proper automake setup should
reduce some of those problems.
* Who wants it? Send me your sourceforge userid. If something you
commit goes horribly wrong, it can always be reverted. That's the
beauty of version control.
Received on 2006-11-12