Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15396
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Function Points |
| Date | 2012-09-02 16:27 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <k20fam$soc$1@speranza.aioe.org> (permalink) |
| References | (17 earlier) <2390503.SVvU42HMcm@sunwukong.fritz.box> <k1tqed$u84$1@speranza.aioe.org> <3906156.YtmnIhlCXh@sunwukong.fritz.box> <k1v3ln$fv2$1@speranza.aioe.org> <7611027.zIGVTbR9Z0@sunwukong.fritz.box> |
"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:7611027.zIGVTbR9Z0@sunwukong.fritz.box...
> Rod Pemberton wrote:
> > "Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
> > news:3906156.YtmnIhlCXh@sunwukong.fritz.box...
> >> Rod Pemberton wrote:
> >> > Can C functions be made which work for novices and idiots? Yes.
> >>
> >> But K&R didn't. However, there are idiots who don't understand why
> >> K&R's ideas were stupid.
> >
> > IMO, their ideas weren't and aren't. E.g., they studied counted
> > strings in a number of languages prior to selecting terminated strings
> > for C, which
> > their B language already used. One of their papers describes why.
> > Their papers, and also Thompson's, discuss other differences too, and
> > the rationale behind their decisions.
>
> 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. Both sub1 and sub2 point to substrings
of string bp.
char bp[]="Hello!";
char *sub1,*sub2;
sub1=bp+3;
sub2=&bp[2];
C has strstr() to locate substrings, strcpy() and strncpy() to copy
substrings, strcat() and strncat() to concatenate substrings, etc.
Did you mean a completely internal substring? E.g., "ell" from "Hello!"?
That's why C has 'n' string functions...
> > 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.
Ignoring the insult, that's not _exactly_ the root cause. The buffer size
is known in C. The root cause is programmer ignoring that, which creates a
coding error when dealing with such boundary situations. Forth is no
different here. E.g., you can store into dictionary space without
allocating the space. Then, whatever you wrote their is overwritten. It
takes at least two Forth words to complete the operation correctly. You've
previously argued that it's the programmer's job to do this correctly. 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. So, why isn't it the
programmer's job in this situation?
> > 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? The programmer has been told what they need to do. If
they don't do it, they've made a mistake. Right? That's what everyone here
argues...
> > The key is making sure dest is sufficiently large.
>
> 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.)
> > If so, then that's not correct. strncpy() only zero pad's if the
> > strlen() of 'src' is less than the third argument which I've called 'n'.
> > For that situation, strncpy() pad's dest with zero's upto 'n'. The size
> > of 'dest' may be larger or smaller than 'n'.
>
> Smaller? That sounds fucking stupid, because then, you have your
> instant buffer overflow.
>
How is this any different from MOVE? Why do you see the problems
with C but not Forth? The size of the buffer at 'c-addr2' is unknown and
can be smaller than 'u', i.e., instant buffer overflow. I mentioned this
previously. Why do you declare C stupid and not Forth?
> > The size of the destination buffer is not
> > passed to the Forth words.
>
> Usual convention is that you pass buffers in addr len form. Then the
> size is known. As I said, you are free to shoot yourself into your foot
> in Forth, but common practice is pretty sane.
>
The functionality is identical to C. Yet, you argue Forth usage is sane and
C usage is insane. Are you irrational?
> Buffer overflows are a real problem in many programs out there.
>
Yes, given Forth has the same problem, Forth is no exception.
> >> No, they figure it out as they go. The problem with C's functions is
> >> that what amount of data they actually move is a surprise to the
> >> programmer, unless he computes it with strlen() before.
> >
> > The size is always known. Where is the "surprise"?
>
> Oh come on. When I write
>
> strcpy(path, getenv("HOME"));
> strcat(path, "/.suided-programrc");
>
> I will be surprised by how long the HOME path actually is, [...]
Who would do that?
getenv() is not standard C. 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.
> [...] 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(). The maximum length of a system variable is known. The
size of 'path' is known. So, if you decided to pass it to system(), then
maybe...
> > I went over this previously. A #define, a declaration, a return from
> > malloc(), sizeof() or strlen() are all able to provide the needed
> > information.
>
> A return from malloc()?
Sorry, the allocation parameter to malloc() is known in advance.
> >> > What they don't generally know is the
> >> > destination buffer's size.
> >>
> >> Which actually is what they should know.
> >
> > No. If programmed correctly, there is no need. The buffer will be
> > sufficiently large to handle what is written to it.
>
> In your ignorant world, yes.
I don't know why you're insulting me on this issue. You've used the same
basic argument numerous times on other issues. So, how is your ignorant
world?
> You don't know what is "sufficiently
> large", as long as the a
>
You failed to complete your reply here. 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? Same reason, yes?
> > How is that any different from strncpy(), strncat(), strncmp() which
> > you just claimed are problems?
>
> You know about strlcat and strlcpy, which solve the problems of strncat
> and strncpy. The problems are:
>
> strncmp/strncpy: They don't tell us if they had to stop because they
> reached the limit.
strncpy() always reaches the limit provided. That's the point of the
padding or truncation. strncmp() reaches the limit or the smallest string
length. I don't see why you need to know if they reached the limit. That's
not the purpose of the functions.
> Actually, they only prevent the harm of the buffer
> overflow, but they silently failed to copy or compare the full string.
That's what strcmp() and strcpy() are for ...
> strncat: This even fails to prevent the actual buffer overflow.
>
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.
> > Those C functions have a specification of
> > how much data they copy (at most).
> >
> >> READ-LINE (the equivalent to gets), ACCEPT, MOVE, etc.
> >
> > Those and CMOVE> and CMOVE all have the same issue as C's strncpy()
> > etc.
>
> No.
Yes. They don't know the size of the buffer they are copying into.
> MOVE is told how many bytes it will *exactly* move. Not an upper
> bound. It doesn't silently fail if the string is longer and doesn't
> forget to zero-terminate it.
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.
> > were allowing the attacker to create collisions. So, for both of
> > those reasons, it's clear to me that their problem is the need of a
> > hash function with fewer collisions.
>
> You are still not understanding anything, which really makes it tedious
> to argue with you. The hash table used for these things has a rather
> small, limited number of buckets, as it is an in-memory key,value hash
> object. 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. There are only a few ways to reduce collisions: increase
the quantity of buckets, reject adding collisions to the table, use
different hash function, use multiple hash functions, "salts", etc. 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.
Are you cutting and pasting "colissions" intentionally since I didn't point
it out at first? You know I spelled it correctly. You read what I wrote.
All you have to do is mimic it.
> > 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.
MurmurHash2 was the better of the two in that regard. The last I checked he
was on MurmurHash3 which I didn't test.
Rod Pemberton
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