Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15404
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Function Points |
| Date | 2012-09-03 00:52 +0200 |
| Organization | 1&1 Internet AG |
| Message-ID | <2365622.2KXcLuKiTj@sunwukong.fritz.box> (permalink) |
| References | (18 earlier) <k1tqed$u84$1@speranza.aioe.org> <3906156.YtmnIhlCXh@sunwukong.fritz.box> <k1v3ln$fv2$1@speranza.aioe.org> <7611027.zIGVTbR9Z0@sunwukong.fritz.box> <k20fam$soc$1@speranza.aioe.org> |
Rod Pemberton wrote:
>> Forth had counted strings, and dismissed that idea later, going to
>> the
>> addr len stack pattern instead. Counted strings and zero-terminated
>> strings share a common stupid thing: You can't point to substrings.
>> Byte-counted strings limit the string size to up to 255 characters,
>> which is also stupid.
>>
>
> I don't know what you mean.
I now understand that you don't understand. Try harder.
> Both sub1 and sub2 point to substrings of string bp.
>
> char bp[]="Hello!";
> char *sub1,*sub2;
>
> sub1=bp+3;
> sub2=&bp[2];
Ok, for the slow thinkers: Let's say we have a forth command line,
consisting of the string
": foo bar 2dup over type ;"
We now want to point to the substring "foo", because that's our name to
define. In Forth, this is just an string+2 3 as addr len pair. In C,
you need to make a copy.
> Did you mean a completely internal substring?
Yes. You should think first and then start to babble.
> E.g., "ell" from "Hello!"? That's why C has 'n' string functions...
I don't actually think that copying a substring to make use of it is a
clever idea. You end up with all the hassles that causes C programs to
go astray: Uh, I need a buffer for that, and I need the buffer before I
know the length...
>> > If you know dest is sufficiently large
>>
>> <tourette>
>> You fucking idiot, the root cause of shitty buffer overflows is that
>> you *don't* fucking know if dest is fucking large enough!
>> </tourette>
>>
>> Do you understand now? It seems to be really hard to pass words
>> through to you.
>>
>
> Forth has the exact same issues. It affects MOVE CMOVE> CMOVE and
> all the other Forth words you listed. You keep ignoring this. So, it
> seems
> to be really hard to pass words through to you also. You now it's
> true. Just agree.
You simply don't understand the issue, and therefore I better should
stop. It's not worth the time. In Forth, you know how much MOVE will
copy *before it starts copying*, as you tell it how much it should copy.
In C, strcpy() doesn't even tell you after it did so, it is implicit.
> Ignoring the insult, that's not _exactly_ the root cause. The buffer
> size is known in C.
Unfortunately only at the point where you declare the buffer. Once you
start passing it around, this information is lost. And that's the
difference to Forth: With the recommended style of passing addr len
buffers, this information is not lost.
> Forth is no different here.
If you ignore the usual style how to deal with buffers, yes, you can do
the same bad things as in C. But in C, it's not ignoring well-
established practice, there it *is* established pratice to pass around
pointers without size as buffers.
> This is no different from not knowing the destination buffer size in
> C when you should know it and when it's available to you.
In a moderately factored C program, the buffer size is not available to
you when you need it. Because due to C's braindead "we pass buffers as
pointers, and don't tell anybody how long they are", this information
gets lost too quickly.
> So, why isn't it the programmer's job in this situation?
To fix elementary design mistakes in a language aren't the programmer's
job.
>> > Of course, you will need to make sure 'dest' is terminated, if you
>> > intend to use it as a string:
>> >
>> > dest[MAX]='\0'; /* MAX is a #define for dest's maximum size */
>>
>> Great. Yes, this is really easy to make it secure. That's why we
>> have these bugs by the 100s in large programs.
>
> How is this any different from a Forth programmer needing to keep
> track of items on the stack?
It's about easy vs. hard to find bugs. The bug above when omitting
dest[MAX]='\0'; is only a problem when you actually run in an overflow
situation. People don't test for overflows, anyways. When you get your
stack items wrong in a Forth word, it is not an occasional problem that
doesn't show up during tests, it shows up quickly.
The stack thing is like a bicycle. You have to keep balance on a
bicycle all the time. This doesn't make a bicycle a particularly crash-
prone vehicle. Your argument is about like "if you turn your wheel in
your car 60° left, at 70mph, it turns over. It doesn't turn over in all
other conditions. How is that different from a bicycle, which requires
you to balance all the time?"
The difference is that tasks you do regularly are automized by your
brain, and handled *much better* than things you don't do regularly.
>> No, the key is that there is no "sufficiently large", because the
>> attacker can always make his attack vector larger.
>
> How is Forth unaffected by this? (It's not.)
By passing the size of buffers around, and making it possible to write
correct code.
> getenv() is not standard C.
This is a rather silly argument. getenv() is both part of C89 and C99.
> Even so, it returns a pointer to a
> _string_. Any sane programmer would then check it's length via
> strlen() prior to strcpy() and strcat() to make sure it fits the
> buffer.
Unfortunately, we have only insane programmers around.
>> [...] and that it contains executable code, allowing
>> the user to gain privilege.
>>
>
> I see nothing which transfers execution to the string. In your
> example,
> it's always a string. It's possible there is a hidden buffer
> overflow, but if coded correctly, 'path' is more than long enough to
> handle the strcpy()
> and strcat().
No. You don't know if path is long enough, and the standard coding
style doesn't give you any way to even check. path may be a buffer
provided by some function above in the call tree, like
char path[60]; /* should be enough, programmer's sloppy reasoning */
tilde_expand(path, "~/.mystupidprogramrc");
> The maximum length of a system variable is known.
No.
http://stackoverflow.com/questions/1078031/what-is-the-maximum-size-of-
an-environment-variable-value
People there created surprisingly large environment variables when
trying to find the limit. It is at least operating system dependent,
and a portable program might run fine on one OS, but be vulnerable to
buffer overflows on another.
> Sorry, the allocation parameter to malloc() is known in advance.
But it is known to some completely different part of the program, which
- by conventional C style - choose to not tell anybody else.
> I don't know why you're insulting me on this issue. You've used the
> same basic argument numerous times on other issues.
I'm clearly not patient enough for a discussion with you ;-).
>> You don't know what is "sufficiently
>> large", as long as the a
>>
>
> You failed to complete your reply here.
Yes, don't know what happend. Maybe a buffer overflow ;-). You don't
know what is "sufficiently large", you are just guessing. And that's a
bad idea. There are two sane ways to deal with buffer sizes: Either
pass them along with the buffer pointer, or adjust the buffer size as
required. I prefer the latter, because it doesn't waste memory in the
typical case (short buffer sufficient), and doesn't fail, as long as
there's enough memory.
> I already told you _how_ a C
> programmer knows the buffer is sufficiently large, repeatedly. How
> does a Forth programmer know the destination buffer at 'c-addr2' is
> sufficiently large?
By checking the length which came together with the addr in an addr len
pair.
> Same reason, yes?
Not at all. Forth programs are factored to quite small entities, so
such sort of a-prior knowledge which you always insist on ("I know how
large my malloced block is"), is not useful in a Forth program.
Actually, it's also not useful in a C program, because C programs tend
to be moderately factored, too (not into the same small entities as a
Forth program, but they are still factored).
> None of the C string functions prevent buffer overflow. Buffer
> overflow is only prevent if the programmer does his/her job and makes
> the destination
> buffer large enough. That's what I've been telling you. Forth has
> the same issue.
Forth passes the size of the destination buffer around as addr len pair
- typical coding style; you can always choose to ignore conventions like
this, but that's the recommended convention.
> So, then we shouldn't be comparing MOVE or CMOVE> to any of the C
> string
> functions, should we? MOVE or CMOVE> moves memory blocks. It should
> be
> compared to the C memory functions which move memory blocks. Let's
> say memcpy() for CMOVE> and memmove() for MOVE.
Unfortunately, C strings are not memory blocks. It would be nice if
they were, because then the whole issue would quickly go away. All
strings, all buffers in C would be addr len pairs, and the knowledge of
their size wouldn't be lost.
MOVE is a low-level building block, if you want to make a buffer-to-
buffer copy (both with addr len) that doesn't overflow, you write
something like
: copy ( addr1 len1 addr2 len2 -- ) rot umin move ;
That's on the edge of becoming a word of its own, so usually, you write
that explicitely, not as a word.
[...]
>> Regardless of how you create your hash function, its key is
>> reduced to a few bits (in the order of 10), and therefore, you can
>> quickly generate a whole lot of colissions.
>>
>
> True. However, their defective implementation doesn't change their
> need for fewer collisions.
How do you know that they have too many collissions? I'm not going to
look at PHP's source code for the risk of immediate brain damage ;-).
An attacker hand-crafted a set of strings so that they would end up in a
single bucket of PHP's hash table, this doesn't indicate that they have
too many collisions in the general case.
> There are only a few ways to reduce collisions:
> increase the quantity of buckets,
Not against a deliberately chosen attack. In Gforth, we automatically
increase the number of buckets depending on how many entries there are
in the hash table, but since the algorithm is deterministic, an attacker
would still be able to create such a set of strings.
> reject adding collisions to the table,
That would violate the spec of the hash table. It stores key,value
pairs. Not adding collisions would break it.
> use different hash function, use multiple hash functions, "salts",
> etc.
IMHO the only way out is some sort of salt/xor which makes the hash
function unpredictable for the attacker. If you have a choice of 10
hash functions in such an attack, the attacker just provides one long
collision chain for each of them, and achieves his slow-down (with the
same amount of data now by a factor of 10 less).
> If they continue to limit the number of buckets, the original cause of
> their problem
> remains. According to you, they fixed the "effect" of the problem
> instead of fixing the "cause" of it.
Yes. Well, you can argue that an attacker who is allowed to fill in
arbitrary values in a globally used table in PHP is a problem in any
case, so removing that capability (which apparently didn't break
programs) is a good idea.
>> > I'm not sure if these are the type of hash functions they need, but
>> > these two public hash functions are good:
>> >
>> > Austin Appleby's MurmurHash2
>> > Bob Jenkins' hashlittle() from lookup3.c
>>
>> hashlittle() is perfect to use for lookups, but it does nothing to
>> prevent this attack.
>
> These two have far fewer collisions than other hash functions I
> checked.
All reasonable hash functions pass a chi² test on non-random data (e.g.
a dictionary), and should have about the same number of collisions.
That's how you test if your hash function is good.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-21 21:43 -0700
Re: Comparative Productivity of Programming Languages "A. K." <akk@nospam.org> - 2012-08-22 07:07 +0200
Re: Comparative Productivity of Programming Languages Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-22 03:35 -0500
Re: Comparative Productivity of Programming Languages John Passaniti <john.passaniti@gmail.com> - 2012-08-22 14:06 -0700
Function Points (was: Comparative Productivity of Programming Languages) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-23 14:50 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-23 11:43 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 14:13 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 10:12 -0700
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-25 15:39 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 15:09 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 12:34 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 16:43 -0700
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-25 18:05 -0700
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-25 20:34 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-26 03:24 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-25 22:44 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 21:19 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 00:36 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-25 21:50 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 01:08 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-26 23:20 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 19:33 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-27 13:34 -0500
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-27 22:38 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 02:45 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 18:14 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 18:24 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:22 +0000
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 03:07 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-28 08:18 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-28 12:15 -0500
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-28 23:05 -0700
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-29 03:55 -0500
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-27 22:28 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 20:26 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-28 23:17 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 01:13 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 02:23 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:59 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 22:18 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 20:44 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-31 01:29 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 09:33 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 02:58 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-29 19:39 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:10 +0000
Re: Function Points gavino_himself <visploveslisp@gmail.com> - 2012-08-30 20:08 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 17:47 -1000
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-27 13:43 -1000
Re: Function Points "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-08-27 12:14 +0100
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-27 05:12 -0700
Re: Function Points "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-08-27 15:52 +0100
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-26 13:09 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 20:52 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-30 14:08 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-30 10:43 -0700
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 08:25 -1000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-30 22:42 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 01:23 -0400
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-31 03:08 -0500
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:56 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 02:35 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-31 23:52 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:27 +0000
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:18 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 17:45 +0200
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 16:14 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 19:13 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 03:19 -0500
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:18 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:04 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 04:02 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 17:40 +0200
Re: Function Points jim@rainbarrel.com - 2012-09-02 10:32 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 20:49 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:33 -0400
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 17:03 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 09:02 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:35 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 13:42 -1000
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:54 -0700
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-03 00:29 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:30 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 21:21 -1000
Re: Function Points jim@rainbarrel.com - 2012-09-03 10:37 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-04 07:14 +0000
Re: Function Points Coos Haak <chforth@hccnet.nl> - 2012-09-03 21:12 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 17:32 -0400
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 17:51 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-03 22:37 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-04 04:25 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-04 07:35 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 02:13 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-04 20:18 -1000
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-05 10:56 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-05 16:11 -0400
Re: Function Points John Passaniti <john.passaniti@gmail.com> - 2012-09-05 14:07 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 16:27 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 00:52 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-02 16:28 -0700
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:48 -0700
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-02 20:21 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 14:45 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:12 -0400
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-02 21:26 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-03 01:06 -0400
Re: Function Points Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-31 03:29 -0700
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-31 10:35 +0000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-31 18:49 -0400
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-01 14:49 +0000
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-09-01 08:36 -1000
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:11 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 01:58 +0200
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 17:54 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:19 -0400
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:05 +0200
Re: Function Points Coos Haak <chforth@hccnet.nl> - 2012-08-31 23:10 +0200
Re: Function Points "Elizabeth D. Rather" <erather@forth.com> - 2012-08-31 15:50 -1000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-01 10:31 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-01 21:52 +0200
Re: Function Points "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-09-01 16:36 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-01 14:36 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 03:30 +0200
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-02 23:15 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-02 15:02 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 01:50 +0200
Re: Function Points jim@rainbarrel.com - 2012-09-02 16:57 -0700
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-03 23:11 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 14:30 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-04 10:14 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-04 22:10 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 00:19 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-06 17:48 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 12:01 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-06 22:02 +0200
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-09-06 14:19 -0700
Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-07 11:30 +0000
Re: Heap (was: Function Points) Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-07 18:12 +0200
Re: Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-07 16:48 +0000
Re: Heap (was: Function Points) Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-07 21:34 +0200
Re: Heap Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-09-07 22:04 +0100
Re: Heap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 11:52 +0000
Re: Heap Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-08 22:48 +0200
Re: Heap (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-08 12:11 +0000
priority queue (was: Function Points) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-03 11:46 +0000
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 15:03 +0200
Re: Function Points mhx@iae.nl (Marcel Hendrix) - 2012-09-03 22:36 +0200
Re: Function Points mhx@iae.nl (Marcel Hendrix) - 2012-09-06 20:27 +0200
Re: Function Points Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-09-02 04:00 -0500
Re: Function Points visualforth@rocketmail.com - 2012-09-03 10:40 -0700
Re: Function Points Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-03 20:26 +0200
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-27 11:49 -0400
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-27 09:16 -0700
Re: Function Points Josh Grams <josh@qualdan.com> - 2012-08-28 22:46 +0000
Re: Function Points jacko <jackokring@gmail.com> - 2012-08-28 16:06 -0700
Re: Function Points Doug Hoffman <glidedog@gmail.com> - 2012-08-28 20:50 -0400
Re: Function Points anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-26 12:59 +0000
Re: Function Points Paul Rubin <no.email@nospam.invalid> - 2012-08-26 22:24 -0700
Re: Function Points (was: Comparative Productivity of Programming Languages) John Passaniti <john.passaniti@gmail.com> - 2012-08-23 15:02 -0700
Re: Function Points (was: Comparative Productivity of Programming Languages) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-25 14:57 +0000
Re: Comparative Productivity of Programming Languages "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-22 08:07 -0400
Re: Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-22 08:12 -0700
Re: Comparative Productivity of Programming Languages visualforth@rocketmail.com - 2012-08-22 07:37 -0700
csiph-web