Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15383
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Function Points |
| Date | 2012-09-02 04:02 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <k1v3ln$fv2$1@speranza.aioe.org> (permalink) |
| References | (15 earlier) <b-mdnS3hM6567d3NnZ2dnUVZ8midnZ2d@supernews.com> <k1rfal$jji$1@speranza.aioe.org> <2390503.SVvU42HMcm@sunwukong.fritz.box> <k1tqed$u84$1@speranza.aioe.org> <3906156.YtmnIhlCXh@sunwukong.fritz.box> |
"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. > > So, Forth doesn't have KEY ... ? > > KEY returns a single value, on the stack. > > > Are you saying I can't place KEY in a LOOP and C, (c-comma) until I > > consume all dictionary space and maybe space beyond that? > > Yes, in Forth you are entitled to shoot yourself into your foot. Are you now agreeing that C, (c-comma) is a "buffer writing word" which _is_ "prone to overflow"? > > Are you saying I CMOVE> doesn't copy into a buffer of unknown space > > just like C's strcpy()? > > Well, with CMOVE>, the programmer needs to know in advance how many > bytes to copy. Perhaps, I should've compared with strncpy() instead of strcpy(). It's closest to CMOVE> . That comparison would've been more accurate. But, strncpy() also copies into a buffer of unknown size, just like CMOVE>. > With strcpy, you don't know in advance, you only know > the two pointers. > That's not true. strcpy() is not for non-strings. So, you can call strlen(), if you don't already have the size from the declaration, a #define, or malloc(). > I know that it is difficult to understand how much C is wrong, so > difficult that people who wanted to fix the problems of strcat came up > with strncat. Did you mean strlcat() and strlcpy()? They were created to fix supposed problems with C's functions. strncat(), strncpy(), strncmp() are a part of ANSI C (1989/90). They actually pre-date ANSI C though. I'd have to check to see if they are a part of K&R C, or came somewhere inbetween, or were even earlier. > strncat transfers up to n bytes from the source to the > end of the string at dest. Well, you don't actually know where the end > of that string actually is, so strncat is not that helpful. It would > have been *much* better if strncat had specified the maximum buffer size > of the dest buffer. Therefore the advice to use strncat is: > > strncat(dest, src, sizeof(dest)-strlen(dest)-1) > Wow, someone made that difficult... If you know dest is sufficiently large and where n<=strlen(src), then: strncat(dest, src, n); Generally, n is less than strlen(src), i.e., n<strlen(src). Why? Well, if n equals strlen(src), i.e. n=strlen(src), then you use strcat(). 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 */ The key is making sure dest is sufficiently large. This is easy to do except for unlimited gets() input. Most input functions limit what they read, like the 'n' string functions. > strncpy is also stupidly designed to fill up the entire buffer with > zeros. WTF? As usual, people now depend on this stupid behavior, > so it's difficult to change... > By "entire buffer" do you mean 'dest'? 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'. E.g., (all unconfirmed) dest="dddddddddd" for 10 chars src="ssssssssss" for 10 chars n=5 10>=5 so strncpy() won't zero pad strncpy will only copy 5 of 10 chars from src strncpy() result should be: "sssssddddd" dest="dddddddddd" for 10 chars src="sssss" for 5 chars n=5 5>=5 so strncpy() won't zero pad strncpy() result should be: "sssssddddd" dest="dddddddddd" for 10 chars src="sss" for 3 chars n=5 3<5 so strncpy() zero pad's the difference strncpy() result should be: "sss00ddddd" - using '0' for '\0' dest="ddddd" for 5 chars src="ssssssssss" for 10 chars n=7 10>=7 so strncpy() won't zero pad strncpy() result should be: "sssssss" 'dest' buffer overflowed by 2 Yes, I looked at 'the manual' to construct those examples. I mostly use non-'n' string functions, without issue. 'the manual' is Harbison and Steele's "C: A Reference Manual", 3rd ed., 1991. > > CMOVE> knows neither. CMOVE> knows the source buffer length, but > > *not* the destination. The destination size is not one of CMOVE>'s > > parameters. > > CMOVE>'s destination size is equal to CMOVE>'s source size. Where do you get that? The size of the destination buffer is not known by CMOVE>. The _user_ specifies how much to copy. The size of the destination buffer is not passed to the Forth words. It's unknown. I.e., the user can overflow the destination buffer. E.g., if the destination buffer is 50 characters and you tell CMOVE> to copy 100 characters, buffer overflow ... There is nothing in Forth-94 saying CMOVE> allocates the destination buffer based on the size passed to it. In fact, if CMOVE> did allocate the destination buffer, it couldn't be passed a pointer for 'caddr-2' since there is no way to determine if sufficient free space exists at 'c-addr2'. Secondly, allocating a buffer for 'c-addr2' would break historical usage of CMOVE>. > >> Insane is > >> > >> c) neither, which is why this language is called C ;-). > >> > > > > You're clearly not familiar with C's functions. > > Or maybe you are not understanding the problem. > I learned C in the early 90s. Excluding gets(), I've never seen this problem. I've read that the problem exists. I've seen a variety of solutions for the problem. I'm now getting an earful from Forth programmers about the problem... Now, I feel much like Ms. Rather, i.e., saying something has never been needed or a cause of any real problem in decades of Forth... > > C's string and memory functions either 1) know the source buffer > > size or 2) know the size of the string being copied. > > 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"? I went over this previously. A #define, a declaration, a return from malloc(), sizeof() or strlen() are all able to provide the needed information. > > 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. > > Given CMOVE> etc, I don't see how that is any different from Forth. > > This is because you don't understand. All Forth words that copy data > have a specification how much data they copy (at most). How is that any different from strncpy(), strncat(), strncmp() which you just claimed are problems? 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. > Come on, I'm really getting bored > now. I'm talking about *this* exploit: > > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4885 > Well, that's new. I admit jump into the thread in the middle, but I can't find any mention of that previously in this thread by you. So, how would I have known that? Did someone else bring it up? I don't see why the double hash method I mentioned at the end of the last post wouldn't resolve their issue, unless they require a single hash value for some reason... They stated that an O(n) response instead of O(1) is a result of the collisions. They also state that substrings and meet-in-the-middle methods 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. I already mentioned that. Or, they need to change something with their "salt" or XOR method, or whatever they're using, so that substrings and meet-in-the-middle methods don't work. Concatenating short strings into larger ones is simple to do. That might prevent the substring problem. I think a "salt" definately would. However, it seems really strange to me that a meet-in-the-middle method - without knowing exactly what that means - would work. Generally, hash functions generate values which don't correlate nicely with the input or with anything. The values appear widely distributed, widely spaced, and "randomly" distributed. An exception would be a perfect hash. So, how does someone generate strings which they can use to create meet-in-the-middle hash collisions? What hash function do they use? 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 Most other publicly (about 50) available hash functions are not good: https://groups.google.com/group/comp.lang.misc/msg/a37141ec795b97fb 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