Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #15078 > unrolled thread
| Started by | visualforth@rocketmail.com |
|---|---|
| First post | 2012-08-21 21:43 -0700 |
| Last post | 2012-08-22 07:37 -0700 |
| Articles | 20 on this page of 163 — 19 participants |
Back to article view | Back to comp.lang.forth
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
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-08-31 18:56 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k1rfal$jji$1@speranza.aioe.org> |
| In reply to | #15300 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message news:b-mdnS3hM6567d3NnZ2dnUVZ8midnZ2d@supernews.com... > Rod Pemberton <do_not_have@notemailnot.cmm> wrote: > > "Bernd Paysan" <bernd.paysan@gmx.de> wrote in message > > news:2250796.QNINORRiYk@sunwukong.fritz.box... [...] > >> But C's main problem is one fundamental mistake: buffers are passed > >> around as pointers, without length. > > > > If you knew anything about C, you'd know that the length of a buffer > > is always known. It's either in the declaration of the buffer, or > > was needed to allocate the buffer dynamicly, or is available with > > sizeof() or strlen() etc. Whether or not the length is available > > when needed is a programmer implementation issue. > > Well, yes. It's the "programmer implementation issue" that Bernd is > talking about. It's the fact that if someone passes you an int[] you > can't say "How big is this?" Yes, you can insist that they also pass > you the size, but that doesn't change the fact that the language > doesn't. > So? Why should the language? Forth doesn't do a bunch of stuff that C does for the user. Forth requires the user to do so: stack mainenance, allocation, etc. So, how is Forth any better than C? IMO, this is a "black pot calling the black kettle 'black'" issue. > >> The other way to deal with that problem is to have a unique hash > >> function, which the attacker can't create hash collisions for (for > >> being "unique", something quite simple is completely sufficient: > >> xor all strings with the same secret). > > > > There is no guarantee that for two non-XOR'd strings which are hash > > collisions that their two XOR'd strings won't be hash collisions > > also. If the hash function has low collisions, then it's unlikely > > the XOR'd strings will collide, but that's also true for the > > non-XOR'd strings. > > You're missing the point. The idea of the unique hash function is not > to make collisions impossible but to make them unpredictable: the > scenario is one where the attacker knows the hash function and > deliberately creates collisions. > What value does that have? After working through the conlusion further below, I can only see XOR-ing of being of very minimal use in preventing some type of pre-computed dictionary attacks involving hash collisions. That's if the use of XOR-ing is kept secret, is indeterminable, and the attacker isn't intelligent enough to determine what is being done. If the attacker knows the hash function and they aren't obtaining the desired collisions, they know something has changed. Since the XOR secret is used on all inputs, if the attacker has the hash values for the host under attack, he only need try numerous secret strings until the hash values begin to match. So, even when using a secret XOR, one must keep the hash values secret too. IIRC, *nix style hosts don't or (didn't) keep the resulting hash lists secret for it's password file. But, there is an even simpler method than XOR-ing to do that. There is no need to XOR. Use a "salt": http://en.wikipedia.org/wiki/Salt_(cryptography) How I came to the conclusion that XOR-ing is of minimal use: There is no need to make collisions "unpredictable" if collisions aren't a problem in some manner. I.e., making collisions "unpredictable" means there is some problem with collisions. The best solution in that case is to reduce the input set and use a hash with a lower frequency or probability of collisions, i.e., a better hash and/or a larger sized hash value. If the attacker knows which hash function is being used, then the attacker knows the entire set of input strings too. Shifting the input set via XOR doesn't eliminate or reduce the overall frequency or probability of collisions generated by the hash. So, the probability that the shifted set collides is the same as the unshifted set. If collisions are occuring at the same rate and those collisions are causing some problem, all the attacker has to do is run the entire input set until he or she finds alternate collisions. Of course, the input set is comprised of limited range character data. So, shifting may reduce collisions overall (or may increase collisions), but it won't change the frequency or probability that collisions will occur. I.e., some collisions are still likely to occur. The attacker just needs to find them. But, that is no different from the original set of strings. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-01 02:35 +0200 |
| Subject | Re: Function Points |
| Message-ID | <2390503.SVvU42HMcm@sunwukong.fritz.box> |
| In reply to | #15344 |
Rod Pemberton wrote: > So? Why should the language? Forth doesn't do a bunch of stuff that > C does > for the user. Forth requires the user to do so: stack mainenance, > allocation, etc. So, how is Forth any better than C? IMO, this is a > "black pot calling the black kettle 'black'" issue. Yes, you don't get stack underflows in C. You get stack overflows in C just as in Forth as error condition - catching both stack under- and overflow is done by guard pages, and therefore not a real issue. You get buffer overflows in C due to the brain-damaged stdlib functions which don't check for buffer size, and these buffer overflows even allow you to overwrite your return address, which is the common attack vector. You can't do that in Forth for two reasons: a) The return stack is in a separate memory region, ideally guarded by unmapped pages (as in Gforth). b) your buffer writing words aren't prone to overflow as in C. However you can shoot yourself into your own foot in many ways in Forth. But, if you have words writing into buffers, there are only two sane ways of doing it: a) the word knows the buffer size, and can stop writing before the buffer overflows b) the word can expand the buffer so that the data will fit. Insane is c) neither, which is why this language is called C ;-). >> You're missing the point. The idea of the unique hash function is >> not to make collisions impossible but to make them unpredictable: the >> scenario is one where the attacker knows the hash function and >> deliberately creates collisions. >> > > What value does that have? > > After working through the conlusion further below, I can only see > XOR-ing of being of very minimal use in preventing some type of > pre-computed dictionary > attacks involving hash collisions. That's if the use of XOR-ing is > kept secret, is indeterminable, and the attacker isn't intelligent > enough to > determine what is being done. Nope. The only thing you have to keep secret is the actual value you are xoring with. > If the attacker knows the hash function > and they aren't obtaining the desired collisions, they know something > has > changed. Since the XOR secret is used on all inputs, if the attacker > has the hash values for the host under attack, he only need try > numerous secret > strings until the hash values begin to match. Yes. And how does he know that they match? The point of these hash attacks is to fill the hash with single, pretty long chain, and then use the degenerated performance of that hash to slow down the machine under attack. The attacker does not actually have any way to deterine how the hash looks like except for the timing of the attacked machine. > So, even when using a > secret > XOR, one must keep the hash values secret too. That's what even PHP on a server does (and PHP does a lot of stupid things). You can't force it to print out the hash table for inspection if your attack is working or not. > IIRC, *nix style hosts > don't or (didn't) keep the resulting hash lists secret for it's > password file. You are confusing things... > But, there is an even simpler method than XOR-ing to do that. There > is no > need to XOR. Use a "salt": > http://en.wikipedia.org/wiki/Salt_(cryptography) That's solving a quite different problem. You can't use salt in a key,value hash table. You can (and should) have salt in a password hash. IMHO, you actually should not use password authentication in the 21st century, as we have much better public key authentication, where stealing a whole shitload of pubkeys from a server doesn't give you anything useful. That's why they are called public keys: They don't have to be hidden. Passwords are shared secrets, and they have to be kept secret; adding salt is helping a bit, but dictionary attacks still work on salted hashs. Most people use words from dictionaries as passwords, and maybe add a single digit. > How I came to the conclusion that XOR-ing is of minimal use: > > There is no need to make collisions "unpredictable" if collisions > aren't a > problem in some manner. I.e., making collisions "unpredictable" means > there > is some problem with collisions. The best solution in that case is to > reduce the input set and use a hash with a lower frequency or > probability of collisions, i.e., a better hash and/or a larger sized > hash value. No. The attack against PHP servers work, because the hashing method is kown. A better hash function doesn't help, because the attacker deliberately uses keys that have the same hash value. Regardless how good your hash function is, as it reduces the key to some small number, there will be colissions. > If the attacker knows which hash function is being used, then the > attacker > knows the entire set of input strings too. Shifting the input set via > XOR doesn't eliminate or reduce the overall frequency or probability > of > collisions generated by the hash. No. But it makes it impossible for the attacker to know the hash function. > So, the probability that the > shifted set > collides is the same as the unshifted set. If collisions are occuring > at the same rate and those collisions are causing some problem, all > the attacker has to do is run the entire input set until he or she > finds > alternate collisions. Of course, the input set is comprised of > limited > range character data. So, shifting may reduce collisions overall (or > may increase collisions), but it won't change the frequency or > probability that > collisions will occur. I.e., some collisions are still likely to > occur. Hash collisions per se are not the problem. The problem is that the attacker deliberately creates a lot of colissions that end up in exactly the same bucket. And then asks for the values in that hash table (which is really a list now). That takes too long, so the server is having troubles responding in time. > The attacker just needs to find them. But, that is no different from > the original set of strings. The difference is that for the orginal set of strings, the attacker can find colissions on his own computer by just enumerating possible strings, and filling them into a hash table - e.g. if your hash-table has 1024 entries, you have a hit rate of just below 0.1%. Just add a million strings to the PHP hash table, print it out bucket by bucket, and you have 1024 different chains of about 1000 matching strings. Now try that on a remote web server where you don't precisely know how the hash function works (even if you know that it uses the xor method), and you also can't inspect the hash table. As usual, to exploit this problem in PHP, you need two bugs together: a) PHP allows the attacker to insert values in a hash table and probe that hash table, which both is not really necessary b) PHP does use one particular hash algorithm b) is common practice, and the bug in PHP was closed by changing a). We are discussing here what you can do when changing a) is not an option (when you absolutely need the other side to inject arbitrary keys into your hash table). You either go to some deterministic search (b-tree or such), *or* you create your malleable hash function. The common theme from CS people who are in trees and merge sort typically is to point out that hash table and quicksort can degenerate to bad performance when deliberately attacked, so their general performance advantage is lost. And the response is that you can mitigate that thread by making the actual hash function hard to guess (in a cryptographic sense hard), and by making the pivot choice of quicksort hard to guess (using random pivot selection). Both is quite trivial, and closes that threat model, without the same performance hit as going to a deterministic upper bound architecture, which is always slower, even when you aren't under attack. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-08-31 23:52 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7x8vcunskj.fsf@ruckus.brouhaha.com> |
| In reply to | #15347 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Nope. The only thing you have to keep secret is the actual value you > are xoring with. Xoring with some constant is not necessarily good enough (it amounts to initializing the hash calculation with a fixed secret value): http://www.eng.tau.ac.il/~yash/C2_039_Wool.pdf The original Crosby and Wallach paper suggested a fancier approach using universal hashing (i.e. with crypto primitives). That's slower on regular CPU's but with AES hardware showing up in recent x86's, maybe it's the best way, if you want to stay with hash tables.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-01 14:27 +0000 |
| Subject | Re: Function Points |
| Message-ID | <2012Sep1.162733@mips.complang.tuwien.ac.at> |
| In reply to | #15353 |
Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Nope. The only thing you have to keep secret is the actual value you
>> are xoring with.
>
>Xoring with some constant is not necessarily good enough (it amounts to
>initializing the hash calculation with a fixed secret value):
>
> http://www.eng.tau.ac.il/~yash/C2_039_Wool.pdf
>
>The original Crosby and Wallach paper suggested a fancier approach using
>universal hashing (i.e. with crypto primitives). That's slower on
>regular CPU's but with AES hardware showing up in recent x86's, maybe
>it's the best way, if you want to stay with hash tables.
Cryptographic hashes won't help at all against the attack described in
the paper above (and the paper already mentions that in the abstract),
and the reason is explained by Bernd and by footnote 2 of the paper
above: Whatever the hash function is, if you only have 2^10 or 2^13
buckets, it is easy to find values that collide in the hash table.
However, the attack works by using exhaustive search over the possible
secret values. The authors claim it is realistic for secret values of
13-14 bits (it needs about 1000 packets per possible secret value).
I, of course would use a full word (32 or 64 bits) as a secret value,
and I don't think that an exhaustive search against that is realistic
(it would require sending about 2^42 packets, which will take a long
time). Actually, in their conclusion the authors write "Thus, it
seems that a random value of 32 bits would render this attack
impractical with today's technology."
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-01 14:18 +0000 |
| Subject | Re: Function Points |
| Message-ID | <2012Sep1.161832@mips.complang.tuwien.ac.at> |
| In reply to | #15347 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>> But, there is an even simpler method than XOR-ing to do that. There
>> is no
>> need to XOR. Use a "salt":
>> http://en.wikipedia.org/wiki/Salt_(cryptography)
>
>That's solving a quite different problem. You can't use salt in a
>key,value hash table.
Not the per-key salt anyway. But if you prepend the same salt to all
strings, it has the same effect as your XOR.
>The common theme from CS people who are in trees and merge sort
>typically is to point out that hash table and quicksort can degenerate
>to bad performance when deliberately attacked, so their general
>performance advantage is lost. And the response is that you can
>mitigate that thread by making the actual hash function hard to guess
>(in a cryptographic sense hard), and by making the pivot choice of
>quicksort hard to guess (using random pivot selection). Both is quite
>trivial, and closes that threat model, without the same performance hit
>as going to a deterministic upper bound architecture, which is always
>slower, even when you aren't under attack.
I have read that mergesort is faster than quicksort, but more
memory-consuming, and that glibc's qsort uses mergesort for
small-enough arrays, and quicksort for the larger ones (probably with
mergesort again for the small-enough sub-arrays).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-01 17:45 +0200 |
| Subject | Re: Function Points |
| Message-ID | <2473789.FLYoW3EqIl@sunwukong.fritz.box> |
| In reply to | #15361 |
Anton Ertl wrote: >>That's solving a quite different problem. You can't use salt in a >>key,value hash table. > > Not the per-key salt anyway. But if you prepend the same salt to all > strings, it has the same effect as your XOR. If your hash algorithm actually is cryptographically strong, yes. Many fast hash algorithms however have easy pre-image attacks, i.e. if you know the hashes of both the salt and the key itself, you can compute the hash of the combined part. Especially if the keys collide, they also will collide with whatever salt you add. Nothing gained. There might be hash algorithms where the XOR method does not gain anything, either. So well, you have to check if it actually works. If your hash has no pre-image problems, you can use the "same salt"- approach. >>The common theme from CS people who are in trees and merge sort >>typically is to point out that hash table and quicksort can degenerate >>to bad performance when deliberately attacked, so their general >>performance advantage is lost. And the response is that you can >>mitigate that thread by making the actual hash function hard to guess >>(in a cryptographic sense hard), and by making the pivot choice of >>quicksort hard to guess (using random pivot selection). Both is quite >>trivial, and closes that threat model, without the same performance >>hit as going to a deterministic upper bound architecture, which is >>always slower, even when you aren't under attack. > > I have read that mergesort is faster than quicksort, but more > memory-consuming, and that glibc's qsort uses mergesort for > small-enough arrays, and quicksort for the larger ones (probably with > mergesort again for the small-enough sub-arrays). Not sure if that's true. Quicksort is in-place sorting, which means it consumes less memory. Less memory means also less bandwidth required, and better use of the cache hierarchy. I've read complaints that quicksort's memory access pattern is "wrong", while mergesort gets it "right", but both do unit-stride sequential access, and the actual data (strings) pointed by these pointers is random access for boths. Quicksort has sequential access in reverse direction on one end, which might hurt (prefetch algorithms often assume that you go upwards). The only unpredictable access in improved quicksort is the random pivot access (for obvious reasons it is unpredictable). For quicksort, you need two running pointers, for mergesort, three. Otherwise, the number of operations per step are quite similar. AFAIK, the argument for qsort in glibc being a merge sort is that it is easier to hack mergesort to detect partially sorted fields, and use the detection to not sort them at all (which overall is cheaper). This is because mergesort first breaks the data into chunks and then sorts them, having sorted sub-arrays, while quicksort puts data into two bins, and only the last stage or recursion produces a total order. Pre-sorted sub-arrays will be split during quicksort. However, the only reasonable way to apply this would be to have mergesort used for larger arrays, and quicksort for the small ones, where you know they aren't pre-sorted. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-01 16:14 +0000 |
| Subject | Re: Function Points |
| Message-ID | <2012Sep1.181418@mips.complang.tuwien.ac.at> |
| In reply to | #15364 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Not the per-key salt anyway. But if you prepend the same salt to all
>> strings, it has the same effect as your XOR.
>
>If your hash algorithm actually is cryptographically strong, yes. Many
>fast hash algorithms however have easy pre-image attacks, i.e. if you
>know the hashes of both the salt and the key itself, you can compute the
>hash of the combined part. Especially if the keys collide, they also
>will collide with whatever salt you add. Nothing gained.
That means that, if "uvw" and "xyz" collide, so will "abcuvw" and
"abcxyz"? Does not sound like a good hash function to me. Which hash
function behaves that way?
>> I have read that mergesort is faster than quicksort, but more
>> memory-consuming, and that glibc's qsort uses mergesort for
>> small-enough arrays, and quicksort for the larger ones (probably with
>> mergesort again for the small-enough sub-arrays).
>
>Not sure if that's true. Quicksort is in-place sorting, which means it
>consumes less memory. Less memory means also less bandwidth required,
>and better use of the cache hierarchy.
There are some numbers at
<http://sources.redhat.com/ml/libc-alpha/2000-03/msg00139.html>. It
seems that it depends on the actual sizes which is faster.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-01 19:13 +0200 |
| Subject | Re: Function Points |
| Message-ID | <7610576.BUnA1peUXU@sunwukong.fritz.box> |
| In reply to | #15366 |
Anton Ertl wrote: > That means that, if "uvw" and "xyz" collide, so will "abcuvw" and > "abcxyz"? Does not sound like a good hash function to me. Which hash > function behaves that way? Gforth's hashkey, at least when the same rotation factor is chosen for all strings (and for longer strings, the rotation factor tends to be 5, though as for short strings we use different rotation factors, and there, different string lengths won't collide). > There are some numbers at > <http://sources.redhat.com/ml/libc-alpha/2000-03/msg00139.html>. It > seems that it depends on the actual sizes which is faster. Apparently, the backward stride access hurts on the Pentium 3. As noted, this depends on the CPU, and is not so easy to determine. For large arrays, allocating a buffer and then not really freeing it (free() does not give the memory back to the OS) is really awful, as mentioned. In-place is a must there. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-09-02 03:19 -0500 |
| Subject | Re: Function Points |
| Message-ID | <cvqdnRO4zcEOi97NnZ2dnUVZ8vadnZ2d@supernews.com> |
| In reply to | #15364 |
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
>> I have read that mergesort is faster than quicksort, but more
>> memory-consuming, and that glibc's qsort uses mergesort for
>> small-enough arrays, and quicksort for the larger ones (probably with
>> mergesort again for the small-enough sub-arrays).
>
> Not sure if that's true. Quicksort is in-place sorting, which means it
> consumes less memory. Less memory means also less bandwidth required,
> and better use of the cache hierarchy. I've read complaints that
> quicksort's memory access pattern is "wrong", while mergesort gets it
> "right", but both do unit-stride sequential access, and the actual data
> (strings) pointed by these pointers is random access for boths.
> Quicksort has sequential access in reverse direction on one end, which
> might hurt (prefetch algorithms often assume that you go upwards). The
> only unpredictable access in improved quicksort is the random pivot
> access (for obvious reasons it is unpredictable).
>
> For quicksort, you need two running pointers, for mergesort, three.
> Otherwise, the number of operations per step are quite similar.
I think that's not really true. The inner loop can be reduced to
repeat
j <- j - 1
until A[j] <= pivot
repeat
i <- i - 1
until A[i] >= pivot
if i < j
exchange A[i] <-> A[j]
else
exit
We don't have to check the indices i and j while scanning: this is why
quicksort is fast.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-01 16:18 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k1tqed$u84$1@speranza.aioe.org> |
| In reply to | #15347 |
"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message news:2390503.SVvU42HMcm@sunwukong.fritz.box... > Rod Pemberton wrote: > > So? Why should the language? Forth doesn't do a bunch of stuff that > > C does > > for the user. Forth requires the user to do so: stack mainenance, > > allocation, etc. So, how is Forth any better than C? IMO, this is a > > "black pot calling the black kettle 'black'" issue. > > Yes, you don't get stack underflows in C. You get stack overflows in C > just as in Forth as error condition - catching both stack under- and > overflow is done by guard pages, and therefore not a real issue. ... > You get buffer overflows in C due to the brain-damaged stdlib > functions which don't check for buffer size, [...] It's not an error with the implementation of the function. It's an error with the implementation of the code. Isn't that what you said about stuff overwriting dictionary space? Can C functions be made which work for novices and idiots? Yes. > [...] and these buffer overflows even allow you to overwrite your > return address, which is the common attack vector. I mentioned this already. I'll repeat. That's not always true. It's true for *most* C implementations. It's true for C implementations which use a stack for both data and control-flow. C doesn't require the use of a stack, nor does C require that control-flow and non control-flow be placed together. > You can't do that in Forth for two reasons: > > a) The return stack is in a separate memory region, ideally guarded by > unmapped pages (as in Gforth). > > b) your buffer writing words aren't prone to overflow as in C. > Except for gets(), C isn't prone to overflow. So, Forth doesn't have KEY ... ? 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? Are you saying I CMOVE> doesn't copy into a buffer of unknown space just like C's strcpy()? > However you can shoot yourself into your own foot in many ways in Forth. > > But, if you have words writing into buffers, there are only two sane > ways of doing it: > > a) the word knows the buffer size, and can stop writing before the > buffer overflows > b) the word can expand the buffer so that the data will fit. > CMOVE> knows neither. CMOVE> knows the source buffer length, but *not* the destination. The destination size is not one of CMOVE>'s parameters. This is no different from strcpy() in C which Anton just decried as one of C's most horrid problems... Is CMOVE> one of Forth's most horrid problems? > Insane is > > c) neither, which is why this language is called C ;-). > You're clearly not familiar with C's functions. C's string and memory functions either 1) know the source buffer size or 2) know the size of the string being copied. What they don't generally know is the destination buffer's size. That's where the overflow occurs. What they also don't know is whether a string has been properly terminated or not. But, that's generally not an issue, unless the programmer constructs a string or has an invalid pointer. Given CMOVE> etc, I don't see how that is any different from Forth. > >> You're missing the point. The idea of the unique hash function is > >> not to make collisions impossible but to make them unpredictable: the > >> scenario is one where the attacker knows the hash function and > >> deliberately creates collisions. > >> > > > > What value does that have? > > > > After working through the conlusion further below, I can only see > > XOR-ing of being of very minimal use in preventing some type of > > pre-computed dictionary attacks involving hash collisions. That's if > > the use of XOR-ing is kept secret, is indeterminable, and the attacker > > isn't intelligent enough to determine what is being done. > > Nope. The only thing you have to keep secret is the actual value you > are xoring with. > If the attacker knows you're using XOR, all he has to do is generate "secret" strings until hashes for a couple other input strings match. You have to keep the hash values secret also. > > If the attacker knows the hash function and they aren't obtaining the > > desired collisions, they know something has changed. Since the XOR > > secret is used on all inputs, if the attacker has the hash values for > > the host under attack, he only need try numerous secret strings until > > the hash values begin to match. > > Yes. And how does he know that they match? He already knows what they are: "... if the attacker has the hash values for the host under attack ..." > The point of these hash attacks is to fill the hash with single, pretty > long chain, and then use the degenerated performance of that hash > to slow down the machine under attack. Why would he use the machine under attack to generate the hash values? He knows the hash function. I'm assuming he knows the hash values too. He can use any machine to generate more hash values. > The attacker does not actually have any way to deterine how the > hash looks like except for the timing of the attacked machine. I thought someone said the hash function was known to the attacker. > IMHO, you actually should not use password authentication in the > 21st century, as we have much better public key authentication, [...] True. > [...] where stealing a whole shitload of pubkeys from a server doesn't > give you anything useful. That's why they are called public keys: They > don't have to be hidden. That's generally true. I don't know if that's entirely true. IIRC, there was a PK encryption method was broken. The hash values can be used to help reveal which function is used, if it's a standard hash function. The size of the hash values and the values themselves can be used to provide information. This is similar to the frequency analysis of letters. Actually, this is similar to your PHP a) problem you mentioned [snipped]. Of course, modifying a standard hash function is a bad idea. It could make it weak enough to crack. So, most attackers are only going to expect standard, proven hash functions to be used. > Passwords are shared secrets, and they have to be kept secret; adding > salt is helping a bit, but dictionary attacks still work on salted > hashs. Most people use words from dictionaries as passwords, and maybe > add a single digit. Most attackers know that. > > How I came to the conclusion that XOR-ing is of minimal use: > > > > There is no need to make collisions "unpredictable" if collisions > > aren't a problem in some manner. I.e., making collisions > > "unpredictable" means there is some problem with collisions. The > > best solution in that case is to reduce the input set and use a hash > > with a lower frequency or probability of collisions, i.e., a better > > hash and/or a larger sized hash value. > > No. The attack against PHP servers work, because the hashing method is > kown. A better hash function doesn't help, because the attacker > deliberately uses keys that have the same hash value. ... > Regardless how good your hash function is, as it reduces the key > to some small number, there will be colissions. Without something like a "salt" or a large range hash, then you'll get collisions with shorter input strings. Is that what you mean? > > If the attacker knows which hash function is being used, then the > > attacker knows the entire set of input strings too. Shifting the input > > set via XOR doesn't eliminate or reduce the overall frequency or > > probability of collisions generated by the hash. > > No. But it makes it impossible for the attacker to know the hash > function. I was pretty sure someone said the hash function was known. > > So, the probability that the shifted set > > collides is the same as the unshifted set. If collisions are occuring > > at the same rate and those collisions are causing some problem, all > > the attacker has to do is run the entire input set until he or she > > finds alternate collisions. Of course, the input set is comprised of > > limited range character data. So, shifting may reduce collisions > > overall (or may increase collisions), but it won't change the frequency > > or probability that collisions will occur. I.e., some collisions are > > still likely to occur. > > Hash collisions per se are not the problem. The problem is that the > attacker deliberately creates a lot of colissions that end up in exactly > the same bucket. And then asks for the values in that hash table (which > is really a list now). That takes too long, so the server is having > troubles responding in time. > Once in the same code for the collision bucket, XOR the original string with a second secret. Hash the second XOR'd version of the string. Hopefully, that will generate few or no collisions for the strings in that particular bucket list. Alternately, you could also use two different hash functions, or multiple salt's per string with the same hash function, etc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-02 03:04 +0200 |
| Subject | Re: Function Points |
| Message-ID | <3906156.YtmnIhlCXh@sunwukong.fritz.box> |
| In reply to | #15374 |
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. >> [...] and these buffer overflows even allow you to overwrite your >> return address, which is the common attack vector. > > I mentioned this already. I'll repeat. That's not always true. It's > true for *most* C implementations. That's what's relevant. You can even have a "strong C" which does check buffers for you, even though normal C doesn't. The pointers of such a C are a bit weird, or you use segments like AS/400. >> You can't do that in Forth for two reasons: >> >> a) The return stack is in a separate memory region, ideally guarded >> by unmapped pages (as in Gforth). >> >> b) your buffer writing words aren't prone to overflow as in C. >> > > Except for gets(), C isn't prone to overflow. And strcat and sprintf, and and and. > 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 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. With strcpy, you don't know in advance, you only know the two pointers. 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. 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) Can you remember that, including the additional -1? This sort of stupidity is a recipie for disaster. 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... > 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. Unlike strncat, which has a source size specified, but not a destination size... > This is no different from strcpy() in C which Anton just > decried as one of > C's most horrid problems... Is CMOVE> one of Forth's most horrid > problems? Not at all. Well, we use MOVE nowadays, because manually checking for which direction to move data hasn't been such a good design decision. >> 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. > 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. > What they don't generally know is the > destination buffer's size. Which actually is what they should know. > 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). READ-LINE (the equivalent to gets), ACCEPT, MOVE, etc. > If the attacker knows you're using XOR, all he has to do is generate > "secret" strings until hashes for a couple other input strings match. > You have to keep the hash values secret also. Yes, of course. That's no problem, as the attacker only can feed data into the hash, but has no way to closely examine the hash. >> Yes. And how does he know that they match? > > He already knows what they are: > "... if the attacker has the hash values for the host under attack > ..." This is not the attack we are looking at. The attacker does not have these values. >> The point of these hash attacks is to fill the hash with single, >> pretty long chain, and then use the degenerated performance of that >> hash to slow down the machine under attack. > > Why would he use the machine under attack to generate the hash values? Because *that*s the attack vector. 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 > He knows the hash function. No, he woudn't, because he doesn't know the secret XOR value. > I'm assuming he knows the hash values too. > He can use any machine to generate more hash values. It isn't fun to discuss with you, because you are always completely missing the point. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-02 04:02 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k1v3ln$fv2$1@speranza.aioe.org> |
| In reply to | #15380 |
"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
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-02 17:40 +0200 |
| Subject | Re: Function Points |
| Message-ID | <7611027.zIGVTbR9Z0@sunwukong.fritz.box> |
| In reply to | #15383 |
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.
Let's say: Nothing from the 70s was really clever.
> Are you now agreeing that C, (c-comma) is a "buffer writing word"
> which _is_ "prone to overflow"?
C, writes *one* single byte. It writes a byte into a single dictionary,
which can be guarded, just like we guard stacks against over- and
underflow.
>> > 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> .
Yes, sort-of. Just that strncpy stops reading after a zero, but doesn't
stop writing. You can only use it for strings. And we use MOVE today,
not CMOVE and CMOVE>.
> That comparison would've been more accurate.
> But, strncpy() also copies into a buffer of unknown size, just like
> CMOVE>.
It copies a known number of bytes, so it is actually possible for the
programmer to cause problems.
> Did you mean strlcat() and strlcpy()? They were created to fix
> supposed problems with C's functions.
No, these were created to fix the problems of the functions which where
supposed to fix the problems, but failed so. And despite the fact, that
strlcat and strlcpy are better designed, they still aren't that
widespread. Glibc doesn't contain them.
> 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.
> 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.
> 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.
> By "entire buffer" do you mean 'dest'?
Of course, dest is the buffer in this context.
> 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.
>> 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.
Yes, and by doing so, he's not surprised about how much will get copied.
> 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.
>> > 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.
A great many programmers have never seen this problem... yet, the world
is full of buffer overflows. Take the sunglasses off, they are cool,
but you don't see through.
> 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...
Buffer overflows are a real problem in many programs out there.
>> 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, and that it
contains executable code, allowing the user to gain privilege.
> 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()? You can't ask C's memory management how big a
malloced block is. Hugh's ALLOCATED is definitely not part of the C
function zoo.
>> > 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. You don't know what is "sufficiently
large", as long as the a
> 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. Actually, they only prevent the harm of the buffer
overflow, but they silently failed to copy or compare the full string.
strncat: This even fails to prevent the actual buffer overflow.
> 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. 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.
>> 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?
Yes. He didn't give the link, but we both knew what issue was meant.
> 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.
> 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.
They don't have any such salt or XOR method. They have been completely
ignorant to the problem for quite a while, and troubles to understand
what to do. They are, after all, PHP programmers. They mitigated the
problem by removing one way to inject large numbers of keywords.
> 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.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | jim@rainbarrel.com |
|---|---|
| Date | 2012-09-02 10:32 -0700 |
| Subject | Re: Function Points |
| Message-ID | <21c50fa7-4c96-4ca4-b52a-3a0dc782fe35@googlegroups.com> |
| In reply to | #15391 |
*having read the argument about MOVE vs C standard library functions and buffer overflow problems with the unnecessary swearing* Sounds like you guys need Diaperglu Forth. It's string and buffer functions check for boundary problems and return errors if something happens. Diaperglu also checks for out of memory problems too. On another issue: One of the things that makes other programming languages more productive than Forth is the availability of ready made programming modules, so that you don't have to rewrite them. For example, Objective-C has modules ready made so you can easily make an iPhone app in minutes. Standard things like Buttons, media players, web views, etc, are already written and you just need to invoke them. However: they have the aforementioned problems inherent in the 'C' style approach. Assumptions of unlimited memory being one of them. Another is in how object oriented classes function where the class 'encapsulates' the data. This means the class has it's own custom data structure and to use it means doing lots of copying and initializing of data that already exists elsewhere. This is partly so that the class can have a pointer to it's parent class. What if you have some existing data you want to describe and don't want to do all that copying? Why can't the description of the class data be separated from the data itself? This way you don't have to copy the data and can leave it alone. Forth has an opportunity to address the issues that have been ignored in the other programming languages approach if it ever decides to add standardized modules. It could make it so that the modules are written in Forth and are portable to all platforms. Soo... the Forth community would just need one repository for these standard 'objects'. With that in mind, what is the minimum number of Forth words required to support standardized modules? I ask this because on another thread someone asked how to add local variables to a standard Forth and it couldn't really be done while adhering to the standard without modifying the Forth compiler itself. Forth already has a very good start with it's ANSI standard, and with the new stuff coming in the next standard to define what to do for 'ambiguous conditions'. Why not take the next step and make Forth a truly extensible language for all uses?
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-02 20:49 +0200 |
| Subject | Re: Function Points |
| Message-ID | <1761108.jOiLFpktur@sunwukong.fritz.box> |
| In reply to | #15392 |
jim@rainbarrel.com wrote: > *having read the argument about MOVE vs C standard library functions > and buffer overflow problems with the unnecessary swearing* I sometimes get pissed if someone misses point after point, and seems to be incapable to comprehend anything. If someone tells me that C has no problems, he's just completely ignorant. > Sounds like you guys need Diaperglu Forth. It's string and buffer > functions check for boundary problems and return errors if something > happens. Diaperglu also checks for out of memory problems too. I'm happy with my small string library which grows buffers so they always fit. Diaperglu Forth seems to be targeted to web development, so maybe Gavino should use it ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-02 16:33 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k20flk$tmc$1@speranza.aioe.org> |
| In reply to | #15393 |
"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message news:1761108.jOiLFpktur@sunwukong.fritz.box... > jim@rainbarrel.com wrote: > > *having read the argument about MOVE vs C standard library functions > > and buffer overflow problems with the unnecessary swearing* > > I sometimes get pissed if someone misses point after point, and seems to > be incapable to comprehend anything. If someone tells me that C has no > problems, he's just completely ignorant. > The point is you're not recognizing that my points are valid. You're simply ignoring or dismissing them. Firstly, you're ignoring or failing to recognize that for every C issue you've mentioned, that Forth has the exact same issues somewhere. Or, you're not comparing the equivalent functionality. Secondly, you're also dismissing valid hash collision solutions. So, it seems that your claims of ignorance and non-comprehension apply to you. Now, if my points weren't valid and true, then they'd apply to me. But, they are true and valid. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-02 17:03 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k20hdn$2e4$1@speranza.aioe.org> |
| In reply to | #15392 |
<jim@rainbarrel.com> wrote in message news:21c50fa7-4c96-4ca4-b52a-3a0dc782fe35@googlegroups.com... > *having read the argument about MOVE vs C standard > library functions and buffer overflow problems with > the unnecessary swearing* Hey, I didn't swear. But, he did surprise me that he got the English correct! I'm wondering if he "cut-n-pasted" it or if he consulted with Passaniti. I only pointed out that Forth and C have the same issues. I didn't make any claims that C was better than Forth. Apparently, his hatred of C is so intense, he can't recognize this as being true. He sees C's problems, but not Forth's, even though they're the same. > Sounds like you guys need Diaperglu Forth. It's real and apparently you're the author. I thought you were joking. I.e., "diaper glue" or "nanny state" Forth, e.g., we need everything to be checked for us ... No offense, but what a poor name choice. I definately don't want to be thinking about real "diaper glue". Yuck! > [snip] Stuff you need to start another thread with. It's possible that those you'd like to read those comments on Forth's future will not see them here. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-09-02 09:02 -1000 |
| Subject | Re: Function Points |
| Message-ID | <qrmdnZplrpbVMN7NnZ2dnUVZ_tWdnZ2d@supernews.com> |
| In reply to | #15391 |
On 9/2/12 5:40 AM, Bernd Paysan 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. Counted strings are still widely (and appropriately) used as a storage format, although passing addr/len on the stack is the preferred method. They are way preferable to null-terminated strings that have to be counted at run-time! A string length of 255 characters is fine for most instances of compiled strings (word names, messages, etc.), and it's easy to add an extended format for the rare (in my experience) case in which you need longer ones. > Let's say: Nothing from the 70s was really clever. Isn't it nice that development didn't end there? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-02 16:35 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k20fp6$u0r$1@speranza.aioe.org> |
| In reply to | #15394 |
"Elizabeth D. Rather" <erather@forth.com> wrote in message news:qrmdnZplrpbVMN7NnZ2dnUVZ_tWdnZ2d@supernews.com... ... > Counted strings are still widely (and appropriately) used as a storage > format, although passing addr/len on the stack is the preferred method. > They are way preferable to null-terminated strings that have to be > counted at run-time! Forth has to count a string at run-time for unknown input too. That's also typically the only place that counting a string is needed in C at run-time. The size of static strings in C are known at compile time and dynamic strings require a known size to be allocated at run-time. Most other uses of strings in C use the entire string. I.e., strlen() is generally not needed. Whatever operation is being performed is done until the null character is found or some limit is reached. BTW, I'm fairly sure I mentioned this to you a while ago, Ms. Rather. :-) Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-09-02 13:42 -1000 |
| Subject | Re: Function Points |
| Message-ID | <nu2dnWhLvpFEc97NnZ2dnUVZ_gGdnZ2d@supernews.com> |
| In reply to | #15398 |
On 9/2/12 10:35 AM, Rod Pemberton wrote: > "Elizabeth D. Rather" <erather@forth.com> wrote in message > news:qrmdnZplrpbVMN7NnZ2dnUVZ_tWdnZ2d@supernews.com... > ... > >> Counted strings are still widely (and appropriately) used as a storage >> format, although passing addr/len on the stack is the preferred method. >> They are way preferable to null-terminated strings that have to be >> counted at run-time! > > Forth has to count a string at run-time for unknown input too. That's also > typically the only place that counting a string is needed in C at run-time. > The size of static strings in C are known at compile time and dynamic > strings require a known size to be allocated at run-time. Most other uses > of strings in C use the entire string. I.e., strlen() is generally not > needed. Whatever operation is being performed is done until the null > character is found or some limit is reached. > > BTW, I'm fairly sure I mentioned this to you a while ago, Ms. Rather. :-) I'm not aware of operations requiring Forth to count strings at run-time, since they are normally stored with a count. Maybe C-based implementations are different, but that would be an inefficiency in the implementation, not inherent in the language spec or common practice. Doesn't performing an operation "until the null character is found or some limit is reached" imply checking every character? That would preclude using string move instructions on processors that have them, wouldn't it? Not to mention of cost of the check? Sorry if this is a rehash... I tend to space out in arguments over how C works, as I have never programmed in C. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web