On Mon, Jul 10, 2006 at 05:35:53PM -0700, Graydon Hoare wrote:
3. That buffer is immediately appended to a heap std::string and data is
parsed from there using safer extractor functions. The extractor
functions all test the length of every extraction against the string
length, and assert
I believe a company called Fortify will allow you to run their security
validation tool (DFA style expert system) against open source code for
free. If I remember properly they found several exploitable issues in the
Kernel.
Might be worth a look.
Joel
Rob Schoening wrote:
I have a somewhat
On Tue, Jul 11, 2006 at 10:16:18AM +0100, [EMAIL PROTECTED] wrote:
I believe a company called Fortify will allow you to run their security
validation tool (DFA style expert system) against open source code for
free. If I remember properly they found several exploitable issues in the
Kernel.
+/* Find, and write to ENCLOSER, the nearest line before POS which
matches
+ ENCLOSER_PATTERN. We remember the last line scanned, and the
matched, to
+ avoid duplication of effort. */
+
+void
+hunk_consumer::find_encloser(size_t pos, string encloser)
+{
+ typedef
On Mon, Jul 10, 2006 at 12:21:46PM -0700, Nathaniel Smith wrote:
Well, umm, blame cmarcelo, I guess :-):
http://del.icio.us/tag/monotone
Ah, right. That's Caio.
As a practical matter, I find it unlikely that the FSF will release a
GPL v3 that somehow cannot be applied to, say... gnupg.
On Mon, Jul 10, 2006 at 10:47:35AM -0700, Eric Anderson wrote:
Content-Description: message body text
[EMAIL PROTECTED] writes:
From: Nathaniel Smith [EMAIL PROTECTED]
Subject: Re: [Monotone-devel] Re: Monotone-devel Digest, Vol 39, Issue
15
[ code to check that mtn process is
Now that we have diff -p support on mainline, is there any reason we
shouldn't make it the default?
(For those who haven't run across this before, diff -p gives output
like:
--- hello 80ad86578e12a12c838cd4ff7ca226aa6bcc44e9
+++ hello 94ebfe438b30bf18631c1846b2891b818f46aa23
@@ -9,3
On Tue, Jul 11, 2006 at 02:48:22PM -0700, Zack Weinberg wrote:
On 7/11/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
+/* Find, and write to ENCLOSER, the nearest line before POS which
matches
+ ENCLOSER_PATTERN. We remember the last line scanned, and the
matched, to
+ avoid duplication of
Not really pointers, just iterators and a lot of complicated
vector-index arithmetic, but see attached; maybe it's clearer?
std::vector iterators are pretty thin wrappers around pointers -- have
a lot of the same risks. The patch looks fine; I just feel more
warm-and-fuzzy when complicated
I rewrote CMD(merge) again according to your suggestions; please have a look?
I was thinking about using commit date as a further heuristic, i.e.
when we have two LCAs neither of which is an ancestor of the other,
merge the newest one first; furthermore, when we have three or more
heads with the
Zack Weinberg [EMAIL PROTECTED] writes:
I was thinking about using commit date as a further heuristic, i.e.
when we have two LCAs neither of which is an ancestor of the other,
merge the newest one first; furthermore, when we have three or more
heads with the same LCA, merge the newest two
On Wed, 2006-07-12 at 02:51 +0100, Bruce Stephens wrote:
Zack Weinberg [EMAIL PROTECTED] writes:
I was thinking about using commit date as a further heuristic, i.e.
when we have two LCAs neither of which is an ancestor of the other,
merge the newest one first; furthermore, when we have
On Tue, Jul 11, 2006 at 06:40:54PM -0700, Zack Weinberg wrote:
I was thinking about using commit date as a further heuristic, i.e.
when we have two LCAs neither of which is an ancestor of the other,
merge the newest one first; furthermore, when we have three or more
heads with the same LCA,
13 matches
Mail list logo
