Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #15414

Re: Function Points

Show all headers | View raw

"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:2365622.2KXcLuKiTj@sunwukong.fritz.box...
> 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.
>

That situation is of low use.  C has strtok() to parse strings.  You also
have other options in C besides copying the internal substring.  You can use
strtok().  You can also manually change the the final character of the
substring to to a null, use the substring, and restore the character when
done.

> > Did you mean a completely internal substring?
>
> Yes.  You should think first and then start to babble.
>

And, again with the unecessary insults.

You didn't _say_ an internal substring.  You said:   "You can't point to
substrings."  You placed no restrictions on which type of substring C
couldn't point to in your claim.  I clearly demonstrated that wasn't true.
I demonstrated that you can point to certain types of substrings in C.

> > 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...

That just shows you don't know C very well.  Honestly, I don't think I've
*ever* needed a substring in C.  Use of substrings in BASIC was quite
common.  Typically, you'll use strrchr(), or rarely strchr(), to find a
delimiter, then change it to null.  Basically, in C, you can perform almost
all string operations with strrchr(), strcpy(), strcat(), and the ability to
set a null character within the string.  If you can't, you're doing
something incorrectly.

> In Forth, you know how much MOVE will
> copy *before it starts copying*,

1) Yes, but you don't know the destination buffer's size for Forth's MOVE.

2) Yes, the same is true for strcpy() and strncpy().  For strncpy(), it
copies exactly 'n' characters, padding with null's if needed.  For strcpy(),
it copies strlen() characters.  Call strlen() if you need to know.

> [...]  as you tell it how much it should copy.

Ditto for strncpy() and strcpy().  You tell strncpy() to copy 'n'
characters.  You tell strcpy() to copy the entire string, which is strlen()
characters.

> In C, strcpy() doesn't even tell you after it did so, it is implicit.
>

strcpy() copies the entire string.  It's length is known via strlen() or the
string allocation via malloc() or the string declaration.

> > 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.

No, it's rarely lost.  It's generally available globally as a preprocessor
#define which can be used almost anywhere an integer value is used.

> And that's the difference to Forth: With the recommended style of
> passing addr len buffers, this information is not lost.
>

The 'addr len' form has other flaws.  The len value doesn't have to match
the string's actual length, e.g., len could be 5, but the string could be
six in length.  If too small, it truncates the string.  If too large, it
overflows a buffer.  With a null terminator, strlen() will always return the
correct length.

PL/1 uses counted strings.  It is one of the language's flaws.

> > 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.
>

How is that any different from MOVE?  MOVE doesn't receive the
destination buffer size.

> > 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.
>

Forth doesn't pass the buffer size either.  All Forth words you mentioned
pass the count to be moved or copied, not the actual buffer size.  Why do
you call C braindead and not Forth too?

> >> 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.
>

Show me where MOVE passes the buffer size.  MOVE passes a count, not the
source or destination buffer size.

> > getenv() is not standard C.
>
> This is a rather silly argument.  getenv() is both part of C89 and C99.
>

Wow, I learned one thing from you: getenv() is an unneeded and useless
function, but then again so is stdlib.h.

> > 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.
>

You suggested doing so.  How do you know your insane?

> >> [...] 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,

Why not?  It was declared or malloc'd somewhere.  A quantity was
required to do that.  Typically, a #define is used for an array's size.
If not, an integer can save it's size.  Or, sizeof() can be used to
determine
it's size.

> [...] and the standard coding
> style doesn't give you any way to even check.

Typically, it's a #define in an include file, the system include file that
defines 'path' and must be included in order to use 'path'...

> [...] 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");
>

Yes, that would stupid.

> > The maximum length of a system variable is known.
>
> No.
>

Yes.

> 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's still a string.  getenv() can only do a few things with it when the
user requests it: point to wherever it's stored in OS memory, allocate space
for it and copy it to application space and/or truncate it.  Either way, for
it to be valid C, strlen() must work for it.

> 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.
>

I don't see how this is any different from anything else C or Forth use to
interface the host OS.  IIRC, C even defines such things as implementation
dependent.  However, the sizes of OS objects are generally provide in an
include, at least for C.  I don't know about all OSes, but many do.

> > 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.
>

How is that different from ALLOT allocationg a buffer in Forth, and then
some other Forth word calling MOVE to write into that buffer?

> You don't know what is "sufficiently large", you are just guessing.

No, you need a specific quantity to declare or allocate.  I.e., it's known.

> > 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.

There is no 'addr len' pair for the destination buffer of MOVE.  There is
only an 'addr'.

> Forth passes the size of the destination buffer around as addr len pair

Where?

> 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.
>

You keep ignoring the fact that _two_ buffers are in use, and the fact that
Forth doesn't pass the length of either.

> 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.

I.e., you have to write a safe Forth version of MOVE and pass around an
extra argument...

> [...]
> >> 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 [...]

It said so in the link you provided, twice.

> 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.
>

True.  But, they do under the attack case.  That's were they're having a
problem.

> 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.
>

There are quite a few hash tests to determine if a hash is "good" or not.
The problem is that they frequently test the hash for some situation which
isn't necessary for a real world hash to have.  I.e., why do I need
"avalanche" behavior or no "funneling", low collisions on binary data, or
good chi2, if I want low collisions on a known set of non-binary, string
data (non-uniform data)?  That's were brute-force testing comes into play.


Rod Pemberton

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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