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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | jim@rainbarrel.com |
|---|---|
| Date | 2012-09-02 16:54 -0700 |
| Subject | Re: Function Points |
| Message-ID | <1a52e35d-a761-4707-b067-09469e0935ec@googlegroups.com> |
| In reply to | #15407 |
> 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? > > Yes. That's what happens. And since C has limited support for declaring compile time data structures, many programmers rely on the null terminated strings. (Like me.) Which means that if you need the length of the string later, you have to scan the string for the null terminator.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2012-09-03 00:29 -0700 |
| Subject | Re: Function Points |
| Message-ID | <36babdc4-fb14-4098-aae2-af23c0701430@googlegroups.com> |
| In reply to | #15410 |
And it's also a total pain in the ass to store a legitimate 0 (perhaps as a delimiter) in a string. If you do, all your standard string functions break! I would love to see a standardised memory/buffer extensions words. Ditto heap management. A buffer system could be built on the heap system...
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-03 01:30 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k21f4p$rc3$1@speranza.aioe.org> |
| In reply to | #15407 |
"Elizabeth D. Rather" <erather@forth.com> wrote in message news:nu2dnWhLvpFEc97NnZ2dnUVZ_gGdnZ2d@supernews.com... > 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. At run-time, Forth must generate a count if the string is dynamic. E.g., if a string is entered from the keyboard, something counts the string. In my interpreter, this should be in the outer or text interpreter. I'm not sure where it is for compiled Forth. (IIRC, this came up at the same time.) > Doesn't performing an operation "until the null character is found or > some limit is reached" imply checking every character? For a simple C implementation, yes, the routine will check every character. Some methods move or compare using the machine's native wordsize, except for the start and end of string which are moved or compared as bytes. Others take alignment into account too. Others will code the routines in assembly, instead of C for speed. Etc. > That would preclude using string move instructions on processors > that have them, wouldn't it? No. x86 is the only processor I'm aware of that has string instructions. It can move, compare, copy, etc strings of an (8-bit) byte and either 2 bytes (16-bits) or 4 bytes (32-bits) at a time, depending on processor mode and special instruction overrides. The newer x86 processors have 64-bit mode, although I'm not sure which sizes are supported for that mode. Although, string instructions are typically precluded since string instructions are either 1) too specialized for many C compilers to use effectively or generate, or 2) too slow. So, many, but not all, C implementations will implement a loop in C to move or compare one character at a time. The processor endianness also affects how code for strings is coded. Typically, RISC processors will access 32-bits or larger at a time. Their byte ordering allows this, whereas x86 can only do that in certain situations - where the string order isn't important. I.e., it could be used for a move, but not for string display. > Not to mention of cost of the check? Yes, there would be a check as part of the loop or control-flow. For x86 string instructions, a check is part of string instructions. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-09-02 21:21 -1000 |
| Subject | Re: Function Points |
| Message-ID | <C9WdnYfma-r7x9nNnZ2dnUVZ_uydnZ2d@supernews.com> |
| In reply to | #15418 |
On 9/2/12 7:30 PM, Rod Pemberton wrote: > "Elizabeth D. Rather" <erather@forth.com> wrote in message > news:nu2dnWhLvpFEc97NnZ2dnUVZ_gGdnZ2d@supernews.com... >> 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. > > At run-time, Forth must generate a count if the string is dynamic. E.g., if > a string is entered from the keyboard, something counts the string. In my > interpreter, this should be in the outer or text interpreter. I'm not sure > where it is for compiled Forth. (IIRC, this came up at the same time.) Yes, that's input. Input proceeds at the speed of the inputting device (which may be a typist or parsing from a file). Once the string has passed this initial processing, it shouldn't ever have to be counted again. >> Doesn't performing an operation "until the null character is found or >> some limit is reached" imply checking every character? > > For a simple C implementation, yes, the routine will check every character. > Some methods move or compare using the machine's native wordsize, except for > the start and end of string which are moved or compared as bytes. Others > take alignment into account too. Others will code the routines in assembly, > instead of C for speed. Etc. Since in Forth the length of a string once entered is known, it never has to be counted again. >> That would preclude using string move instructions on processors >> that have them, wouldn't it? > > No. > > x86 is the only processor I'm aware of that has string instructions. It can > move, compare, copy, etc strings of an (8-bit) byte and either 2 bytes > (16-bits) or 4 bytes (32-bits) at a time, depending on processor mode and > special instruction overrides. The newer x86 processors have 64-bit mode, > although I'm not sure which sizes are supported for that mode. > > Although, string instructions are typically precluded since string > instructions are either 1) too specialized for many C compilers to use > effectively or generate, or 2) too slow. So, many, but not all, C > implementations will implement a loop in C to move or compare one character > at a time. The processor endianness also affects how code for strings is > coded. Typically, RISC processors will access 32-bits or larger at a time. > Their byte ordering allows this, whereas x86 can only do that in certain > situations - where the string order isn't important. I.e., it could be used > for a move, but not for string display. > >> Not to mention of cost of the check? > > Yes, there would be a check as part of the loop or control-flow. For x86 > string instructions, a check is part of string instructions. In any case, it seems to me more efficient to maintain what you know about lengths of strings than to have to re-determine it, checking every character in case it's a null. Most processors are very good at managing a loop on a count which is known in advance. 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 | jim@rainbarrel.com |
|---|---|
| Date | 2012-09-03 10:37 -0700 |
| Subject | Re: Function Points |
| Message-ID | <6ec8c2c5-a81d-409a-884e-54456f80ccaf@googlegroups.com> |
| In reply to | #15419 |
> In any case, it seems to me more efficient to maintain what you know
>
> about lengths of strings than to have to re-determine it, checking every
>
> character in case it's a null. Most processors are very good at managing
>
> a loop on a count which is known in advance.
I take back some of what I said about C and compile time data. You can do this in at least gcc and visual studio as of version 6 and it works:
declare a compile time string constant using:
const char* dg_forthsethlistelementvaluename = "SET-ELEMENT-VALUE$";
then reference it's compile time determined length using the sizeof operator:
presortedstringwords[i].namelength = sizeof(dg_forthsethlistelementvaluename);
However I don't take it all back. Supposedly the C community added support for compile time data structures to the standard. You are also supposed to be able to do this:
const struct Premadeword mypresortederrorwords[] = {
{ dg_accessdeniederrorname, sizeof(dg_accessdeniederrorname),
DG_CORE_BUFFERID, (UINT32)&dg_forthdocompiletypedpushdn,
DG_CORE_BUFFERID, (UINT32)dg_accessdeniederror},
{ dg_alreadyfreeerrorname, sizeof(dg_alreadyfreeerrorname),
DG_CORE_BUFFERID, (UINT32)&dg_forthdocompiletypedpushdn,
DG_CORE_BUFFERID, (UINT32)dg_alreadyfreeerror},
};
But the modern C compilers I use don't work correctly. Sometimes sizeof becomes erroneusly 0. Has to be later than the definition in the same file when it's supposed to export to other files... stuff like that.
Even just the string constant stuff has some 'quirks'.
Which is my beef with C in general. They throw all this stuff into the language then don't test it to see if it works correctly before releasing it to the general public.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-09-04 07:14 +0000 |
| Subject | Re: Function Points |
| Message-ID | <2012Sep4.091452@mips.complang.tuwien.ac.at> |
| In reply to | #15425 |
jim@rainbarrel.com writes:
>I take back some of what I said about C and compile time data. You can do this in at least gcc and visual studio as of version 6 and it works:
>
>declare a compile time string constant using:
>const char* dg_forthsethlistelementvaluename = "SET-ELEMENT-VALUE$";
>
>then reference it's compile time determined length using the sizeof operator:
>presortedstringwords[i].namelength = sizeof(dg_forthsethlistelementvaluename);
What works? This gives you the size of a pointer. I just tested this with:
const char *x="bla";
main()
{
printf("sizeof(x)=%d\n",sizeof(x));
return 0;
}
and it prints 8 (the size of a pointer).
However, what works, to some extent, is:
#include <stdio.h>
const char x[]="bla";
main()
{
printf("sizeof(x)=%d\n",sizeof(x));
return 0;
}
This prints 4 (it includes the terminating NUL, which strlen()
doesn't). But in order to make use of that, you have to put every
string in a separate variable, and have a separate sizeof for each of
them. A little cumbersome if you want to deal with a big table of
strings.
- 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 | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2012-09-03 21:12 +0200 |
| Subject | Re: Function Points |
| Message-ID | <184yzunzqaxs5.1gi1kqrlj61hj.dlg@40tude.net> |
| In reply to | #15418 |
Op Mon, 3 Sep 2012 01:30:37 -0400 schreef Rod Pemberton: <snip> > x86 is the only processor I'm aware of that has string instructions. It can > move, compare, copy, etc strings of an (8-bit) byte and either 2 bytes > (16-bits) or 4 bytes (32-bits) at a time, depending on processor mode and > special instruction overrides. The newer x86 processors have 64-bit mode, > although I'm not sure which sizes are supported for that mode. What about Z80 with LDIR LDDR CPIR CPDR etc? -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-03 17:32 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k237g2$ctq$1@speranza.aioe.org> |
| In reply to | #15429 |
"Coos Haak" <chforth@hccnet.nl> wrote in message news:184yzunzqaxs5.1gi1kqrlj61hj.dlg@40tude.net... > Op Mon, 3 Sep 2012 01:30:37 -0400 schreef Rod Pemberton: > > <snip> > > x86 is the only processor I'm aware of that has string instructions. It can > > move, compare, copy, etc strings of an (8-bit) byte and either 2 bytes > > (16-bits) or 4 bytes (32-bits) at a time, depending on processor mode and > > special instruction overrides. The newer x86 processors have 64-bit mode, > > although I'm not sure which sizes are supported for that mode. > > What about Z80 with LDIR LDDR CPIR CPDR etc? > I'm not familiar with it. I'm sure other platforms have string instructions also. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-03 17:51 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k238kl$fj8$1@speranza.aioe.org> |
| In reply to | #15407 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message
news:27f57409-29da-4c88-b288-9b366db8544b@googlegroups.com...
...
> Here's the only thing you need to know about C:
> One of the smartest things the creators of C did
> was to make a sharp dividing line between the language
> and its libraries. So a C programmer is in no way forced
> to use null-terminated strings or the string libraries; just
> as in Forth, you're completely free to come up with your
> own string representation and call your own functions on them.
>
> The only place where the C *language* uses null-terminated
> strings is when the programmer declares a string literal of
> unknown length (versus initializing an array of known length):
>
> char* example = "null terminated";
>
So... You're saying C doesn't use null-terminated strings here?
char c;
c=3["0123456789"];
Nor here?
printf("Hello World!\n");
Neither of the those situations involve a *declaration* of a string literal
as you've claimed, i.e., no keyword 'char' and no variable naming the
string. In both places, the C *language* uses undeclared, null-terminated
strings.
I.e., anywhere there is a string literal, there will be a null-terminator.
Yes? It's one of the parsing phases...
> Sorry, I was typing faster than thinking again
Yup.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-09-03 22:37 -0700 |
| Subject | Re: Function Points |
| Message-ID | <0c6f7076-1afc-4455-9e59-5c9b0a05a027@googlegroups.com> |
| In reply to | #15433 |
On Monday, September 3, 2012 5:49:15 PM UTC-4, Rod Pemberton wrote:
> So... You're saying C doesn't use null-terminated strings here?
>
> char c;
> c=3["0123456789"];
Thanks for your obfuscated C code entry. Yes, there is certainly a null terminator in the string literal, but C is in no way *using* the null in that expression. This particular idiom, which is equivalently (but more conventionally) expressed like this:
printableDigit = "0123456789"[x];
Also has a null-terminator wasting a byte in memory, but the programmer isn't using it.
> Nor here?
>
> printf("Hello World!\n");
Yes, it is indeed using the null terminator there and it's another example of C standard library functions that programmers are under no obligation to use. Thanks for expanding the scope of my statement to include the I/O functions that operate on strings.
> Neither of the those situations involve a *declaration* of a string literal
> as you've claimed, i.e., no keyword 'char' and no variable naming the
> string. In both places, the C *language* uses undeclared, null-terminated
> strings.
Regardless of if the string literal has been given a name or is simply an anonymous pointer to a block of memory, my statement was that string literals are the only place in the C *language* where null-terminated strings exist. C programmers who wish to avoid the potential dangers and performance issues of null-terminated strings only have to deal with string literals. It's the only place where the C *language* forces null-terminators, even if they aren't used.
> I.e., anywhere there is a string literal, there will be a null-terminator.
> Yes? It's one of the parsing phases...
Yes, there will be a null terminator. Just like I originally wrote. The programmer is not forced to use any functions in <string.h> or <stdio.h> or any other functions that use null terminated strings.
> > Sorry, I was typing faster than thinking again
>
> Yup.
Nope.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-04 04:25 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k24dol$n7$1@speranza.aioe.org> |
| In reply to | #15440 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message news:0c6f7076-1afc-4455-9e59-5c9b0a05a027@googlegroups.com... ... > [...] my statement was that string literals are the only place > in the C *language* where null-terminated strings exist. You may think that was what you said. It wasn't. Your original statement includes "declares" and "unknown length". This one doesn't have either. Your statement was: > "The only place where the C *language* uses null-terminated > strings is when the programmer declares a string literal of > unknown length [...]" You can just say, "Sorry, what I meant to say was ... " Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-09-04 07:35 -0700 |
| Subject | Re: Function Points |
| Message-ID | <378e15cb-4d4e-4005-9067-505386a62f2b@googlegroups.com> |
| In reply to | #15443 |
On Tuesday, September 4, 2012 4:22:48 AM UTC-4, Rod Pemberton wrote:
> You may think that was what you said. It wasn't. Your original
> statement includes "declares" and "unknown length".
Yes, because when you declare a string of known length:
char example[8] = "zot";
Then the string isn't null terminated. To be precise (and I know you love to be achingly, tediously, ridiculously precise), the string here is zero-padded.
Thanks for playing, Rod.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-05 02:13 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k26qd1$n8j$1@speranza.aioe.org> |
| In reply to | #15452 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message news:378e15cb-4d4e-4005-9067-505386a62f2b@googlegroups.com... > On Tuesday, September 4, 2012 4:22:48 AM UTC-4, Rod Pemberton wrote: > > You may think that was what you said. It wasn't. Your original > > statement includes "declares" and "unknown length". > > Yes, because when you declare a string of known length: > > char example[8] = "zot"; > > Then the string isn't null terminated. To be precise [...] > the string here is zero-padded. > Since you apparently think that is true, feel free to cite K&R, ANSI, or ISO C specifications. > [...] (and I know you love to be achingly, tediously, ridiculously > precise) [...] If you were trying to be "achingly, tediously, ridiculously precise" for my benefit, why wouldn't you use at least use a word or phrase in regards to null termination that's actually in the C specifications? > Thanks for playing, Rod. I'm not sure why you're thanking me. Every time you say something, I've clearly demonstrated what you say is false, despite your attempts to present your falsehoods as correct. I'm not an authority, and I keep finding provable errors with what you say. That's ignoring the fact you never post anything Forth related, i.e., you're just a nuisance. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-09-04 20:18 -1000 |
| Subject | Re: Function Points |
| Message-ID | <BPGdnX1dxsVMc9vNnZ2dnUVZ_vSdnZ2d@supernews.com> |
| In reply to | #15468 |
On 9/4/12 8:13 PM, Rod Pemberton wrote: ... > That's ignoring the fact you never post anything Forth related, i.e., you're > just a nuisance. 90% of this discussion hasn't been Forth-related. If you guys disagree about null-terminated strings in C you should fight it out in comp.lang.C, IMO. 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 | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-09-05 10:56 -0700 |
| Subject | Re: Function Points |
| Message-ID | <0b400690-5875-4db3-bd71-d7953b9a59f4@googlegroups.com> |
| In reply to | #15468 |
On Wednesday, September 5, 2012 2:10:44 AM UTC-4, Rod Pemberton wrote: > > char example[8] = "zot"; > > > > > Then the string isn't null terminated. To be precise [...] > > the string here is zero-padded. > > Since you apparently think that is true, feel free to cite K&R, ANSI, or ISO > C specifications. You're the kind of copy-and-paste, and I wouldn't dare try to dethrone you. You're free to provide evidence to the contrary. > > Thanks for playing, Rod. > > I'm not sure why you're thanking me. Every time you say something, I've > clearly demonstrated what you say is false, despite your attempts to present > your falsehoods as correct. I'm not an authority, and I keep finding > provable errors with what you say. I'm waiting to see the error here. At most, you pointed out an imprecise use of language on my part. You haven't yet "proved" that the larger statement (that C programmers-- especially embedded systems programmers-- are in no way required to use any of the standard library functions to work with strings.) > That's ignoring the fact you never post anything Forth related, i.e., you're > just a nuisance. Correct. Ignore me. Do you need help setting up a kill file?
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-05 16:11 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k28bh0$p48$1@speranza.aioe.org> |
| In reply to | #15479 |
"John Passaniti" <john.passaniti@gmail.com> wrote in message news:0b400690-5875-4db3-bd71-d7953b9a59f4@googlegroups.com... > On Wednesday, September 5, 2012 2:10:44 AM UTC-4, Rod Pemberton wrote: >> JP ... > > > char example[8] = "zot"; > > > > > > Then the string isn't null terminated. To be precise [...] > > > the string here is zero-padded. > > > Since you apparently think that is true, feel free to cite K&R, > > ANSI, or ISO C specifications. > > You're the kind of copy-and-paste, and I wouldn't dare try to > dethrone you. You're free to provide evidence to the contrary. You could learn something. It's clear I didn't want to look it up. So, you might learn you're correct. Why the fear of finding out? Are you saying you can dish out insults to everyone, but not prove your claims? > You haven't yet "proved" that the larger statement (that C > programmers-- especially embedded systems programmers-- > are in no way required to use any of the standard library > functions to work with strings.) Well, that's because I agree with the larger statement. Did you see me take issue with it? The C language can be used on it's own. However, it's a bit more difficult to do so without C's file I/O functions. They are about all you need from the C libraries. If you actually had a memory and remembered what you read, you'd know that was my position since it has been stated here on multiple occasions. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2012-09-05 14:07 -0700 |
| Subject | Re: Function Points |
| Message-ID | <f6015e10-f41c-4858-aa43-84bde24e4eb9@googlegroups.com> |
| In reply to | #15485 |
On Wednesday, September 5, 2012 4:09:08 PM UTC-4, Rod Pemberton wrote: > You could learn something. It's clear I didn't want to look it up. So, you > might learn you're correct. Why the fear of finding out? Are you saying > you can dish out insults to everyone, but not prove your claims? At this point, I have no idea what you think I got incorrect. I know it's some incredibly subtle use or misuse of language that nobody but you and your /seriously/ pompous assness cares about. Is it the word "use"? Is is that when talking about standard library functions that use strings, I didn't include printf? Please Rod, let me know what incredibly tiny meaningless waste of time argument you're making here. > > You haven't yet "proved" that the larger statement (that C > > programmers-- especially embedded systems programmers-- > > are in no way required to use any of the standard library > > functions to work with strings.) > > Well, that's because I agree with the larger statement. Did > you see me take issue with it? Ah, I should have known. The real problem here is that I wrote a message and felt the need to knee-jerk out a tedious pendant response. No, that's not fair. Please, do let me know what horrible misrepresentation of C that I've provided here. After all, there are children here. > The C language can be used on it's own. However, it's a bit more difficult > to do so without C's file I/O functions. They are about all you need from > the C libraries. Not in an embedded system. Most of the systems I've coded over the years (and many of the others that I've worked on from others) were "bare metal" systems without an operating system. The I/O library of functions is useless when your front panel is composed of LEDs, knobs, and switches. Tell me how the I/O library is at all useful in such a system. More recently, some of these systems have had serial ports for debugging. I typically implement one of the C-based Forths and use that as my monitor program. But even when that's not the case, I don't find it terribly useful to use printf and friends. > If you actually had a memory and remembered what you read, you'd know that > was my position since it has been stated here on multiple occasions. This assumes I read everything you've written. I don't. I know it may come as a shock, but there are probably others in this newsgroup who also don't rush to the computer when another message from Rod is posted in comp.lang.forth. I
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnot.cmm> |
|---|---|
| Date | 2012-09-02 16:27 -0400 |
| Subject | Re: Function Points |
| Message-ID | <k20fam$soc$1@speranza.aioe.org> |
| In reply to | #15391 |
"Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
news:7611027.zIGVTbR9Z0@sunwukong.fritz.box...
> Rod Pemberton wrote:
> > "Bernd Paysan" <bernd.paysan@gmx.de> wrote in message
> > news:3906156.YtmnIhlCXh@sunwukong.fritz.box...
> >> Rod Pemberton wrote:
> >> > Can C functions be made which work for novices and idiots? Yes.
> >>
> >> But K&R didn't. However, there are idiots who don't understand why
> >> K&R's ideas were stupid.
> >
> > IMO, their ideas weren't and aren't. E.g., they studied counted
> > strings in a number of languages prior to selecting terminated strings
> > for C, which
> > their B language already used. One of their papers describes why.
> > Their papers, and also Thompson's, discuss other differences too, and
> > the rationale behind their decisions.
>
> Forth had counted strings, and dismissed that idea later, going to the
> addr len stack pattern instead. Counted strings and zero-terminated
> strings share a common stupid thing: You can't point to substrings.
> Byte-counted strings limit the string size to up to 255 characters,
> which is also stupid.
>
I don't know what you mean. Both sub1 and sub2 point to substrings
of string bp.
char bp[]="Hello!";
char *sub1,*sub2;
sub1=bp+3;
sub2=&bp[2];
C has strstr() to locate substrings, strcpy() and strncpy() to copy
substrings, strcat() and strncat() to concatenate substrings, etc.
Did you mean a completely internal substring? E.g., "ell" from "Hello!"?
That's why C has 'n' string functions...
> > If you know dest is sufficiently large
>
> <tourette>
> You fucking idiot, the root cause of shitty buffer overflows is that
> you *don't* fucking know if dest is fucking large enough!
> </tourette>
>
> Do you understand now? It seems to be really hard to pass words
> through to you.
>
Forth has the exact same issues. It affects MOVE CMOVE> CMOVE and
all the other Forth words you listed. You keep ignoring this. So, it seems
to be really hard to pass words through to you also. You now it's true.
Just
agree.
Ignoring the insult, that's not _exactly_ the root cause. The buffer size
is known in C. The root cause is programmer ignoring that, which creates a
coding error when dealing with such boundary situations. Forth is no
different here. E.g., you can store into dictionary space without
allocating the space. Then, whatever you wrote their is overwritten. It
takes at least two Forth words to complete the operation correctly. You've
previously argued that it's the programmer's job to do this correctly. This
is no different from not knowing the destination buffer size in C when you
should know it and when it's available to you. So, why isn't it the
programmer's job in this situation?
> > Of course, you will need to make sure 'dest' is terminated, if you
> > intend to use it as a string:
> >
> > dest[MAX]='\0'; /* MAX is a #define for dest's maximum size */
>
> Great. Yes, this is really easy to make it secure. That's why we have
> these bugs by the 100s in large programs.
>
How is this any different from a Forth programmer needing to keep track of
items on the stack? The programmer has been told what they need to do. If
they don't do it, they've made a mistake. Right? That's what everyone here
argues...
> > The key is making sure dest is sufficiently large.
>
> No, the key is that there is no "sufficiently large", because the
> attacker can always make his attack vector larger.
>
How is Forth unaffected by this? (It's not.)
> > If so, then that's not correct. strncpy() only zero pad's if the
> > strlen() of 'src' is less than the third argument which I've called 'n'.
> > For that situation, strncpy() pad's dest with zero's upto 'n'. The size
> > of 'dest' may be larger or smaller than 'n'.
>
> Smaller? That sounds fucking stupid, because then, you have your
> instant buffer overflow.
>
How is this any different from MOVE? Why do you see the problems
with C but not Forth? The size of the buffer at 'c-addr2' is unknown and
can be smaller than 'u', i.e., instant buffer overflow. I mentioned this
previously. Why do you declare C stupid and not Forth?
> > The size of the destination buffer is not
> > passed to the Forth words.
>
> Usual convention is that you pass buffers in addr len form. Then the
> size is known. As I said, you are free to shoot yourself into your foot
> in Forth, but common practice is pretty sane.
>
The functionality is identical to C. Yet, you argue Forth usage is sane and
C usage is insane. Are you irrational?
> Buffer overflows are a real problem in many programs out there.
>
Yes, given Forth has the same problem, Forth is no exception.
> >> No, they figure it out as they go. The problem with C's functions is
> >> that what amount of data they actually move is a surprise to the
> >> programmer, unless he computes it with strlen() before.
> >
> > The size is always known. Where is the "surprise"?
>
> Oh come on. When I write
>
> strcpy(path, getenv("HOME"));
> strcat(path, "/.suided-programrc");
>
> I will be surprised by how long the HOME path actually is, [...]
Who would do that?
getenv() is not standard C. Even so, it returns a pointer to a _string_.
Any sane programmer would then check it's length via strlen() prior to
strcpy() and strcat() to make sure it fits the buffer.
> [...] and that it contains executable code, allowing
> the user to gain privilege.
>
I see nothing which transfers execution to the string. In your example,
it's always a string. It's possible there is a hidden buffer overflow, but
if coded correctly, 'path' is more than long enough to handle the strcpy()
and strcat(). The maximum length of a system variable is known. The
size of 'path' is known. So, if you decided to pass it to system(), then
maybe...
> > I went over this previously. A #define, a declaration, a return from
> > malloc(), sizeof() or strlen() are all able to provide the needed
> > information.
>
> A return from malloc()?
Sorry, the allocation parameter to malloc() is known in advance.
> >> > What they don't generally know is the
> >> > destination buffer's size.
> >>
> >> Which actually is what they should know.
> >
> > No. If programmed correctly, there is no need. The buffer will be
> > sufficiently large to handle what is written to it.
>
> In your ignorant world, yes.
I don't know why you're insulting me on this issue. You've used the same
basic argument numerous times on other issues. So, how is your ignorant
world?
> You don't know what is "sufficiently
> large", as long as the a
>
You failed to complete your reply here. I already told you _how_ a C
programmer knows the buffer is sufficiently large, repeatedly. How does a
Forth programmer know the destination buffer at 'c-addr2' is sufficiently
large? Same reason, yes?
> > How is that any different from strncpy(), strncat(), strncmp() which
> > you just claimed are problems?
>
> You know about strlcat and strlcpy, which solve the problems of strncat
> and strncpy. The problems are:
>
> strncmp/strncpy: They don't tell us if they had to stop because they
> reached the limit.
strncpy() always reaches the limit provided. That's the point of the
padding or truncation. strncmp() reaches the limit or the smallest string
length. I don't see why you need to know if they reached the limit. That's
not the purpose of the functions.
> Actually, they only prevent the harm of the buffer
> overflow, but they silently failed to copy or compare the full string.
That's what strcmp() and strcpy() are for ...
> strncat: This even fails to prevent the actual buffer overflow.
>
None of the C string functions prevent buffer overflow. Buffer overflow is
only prevent if the programmer does his/her job and makes the destination
buffer large enough. That's what I've been telling you. Forth has the same
issue.
> > Those C functions have a specification of
> > how much data they copy (at most).
> >
> >> READ-LINE (the equivalent to gets), ACCEPT, MOVE, etc.
> >
> > Those and CMOVE> and CMOVE all have the same issue as C's strncpy()
> > etc.
>
> No.
Yes. They don't know the size of the buffer they are copying into.
> MOVE is told how many bytes it will *exactly* move. Not an upper
> bound. It doesn't silently fail if the string is longer and doesn't
> forget to zero-terminate it.
So, then we shouldn't be comparing MOVE or CMOVE> to any of the C string
functions, should we? MOVE or CMOVE> moves memory blocks. It should be
compared to the C memory functions which move memory blocks. Let's say
memcpy() for CMOVE> and memmove() for MOVE.
> > were allowing the attacker to create collisions. So, for both of
> > those reasons, it's clear to me that their problem is the need of a
> > hash function with fewer collisions.
>
> You are still not understanding anything, which really makes it tedious
> to argue with you. The hash table used for these things has a rather
> small, limited number of buckets, as it is an in-memory key,value hash
> object. Regardless of how you create your hash function, its key is
> reduced to a few bits (in the order of 10), and therefore, you can
> quickly generate a whole lot of colissions.
>
True. However, their defective implementation doesn't change their need for
fewer collisions. There are only a few ways to reduce collisions: increase
the quantity of buckets, reject adding collisions to the table, use
different hash function, use multiple hash functions, "salts", etc. If they
continue to limit the number of buckets, the original cause of their problem
remains. According to you, they fixed the "effect" of the problem instead
of fixing the "cause" of it.
Are you cutting and pasting "colissions" intentionally since I didn't point
it out at first? You know I spelled it correctly. You read what I wrote.
All you have to do is mimic it.
> > I'm not sure if these are the type of hash functions they need, but
> > these two public hash functions are good:
> >
> > Austin Appleby's MurmurHash2
> > Bob Jenkins' hashlittle() from lookup3.c
>
> hashlittle() is perfect to use for lookups, but it does nothing to
> prevent this attack.
>
These two have far fewer collisions than other hash functions I checked.
MurmurHash2 was the better of the two in that regard. The last I checked he
was on MurmurHash3 which I didn't test.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-09-03 00:52 +0200 |
| Subject | Re: Function Points |
| Message-ID | <2365622.2KXcLuKiTj@sunwukong.fritz.box> |
| In reply to | #15396 |
Rod Pemberton wrote:
>> Forth had counted strings, and dismissed that idea later, going to
>> the
>> addr len stack pattern instead. Counted strings and zero-terminated
>> strings share a common stupid thing: You can't point to substrings.
>> Byte-counted strings limit the string size to up to 255 characters,
>> which is also stupid.
>>
>
> I don't know what you mean.
I now understand that you don't understand. Try harder.
> Both sub1 and sub2 point to substrings of string bp.
>
> char bp[]="Hello!";
> char *sub1,*sub2;
>
> sub1=bp+3;
> sub2=&bp[2];
Ok, for the slow thinkers: Let's say we have a forth command line,
consisting of the string
": foo bar 2dup over type ;"
We now want to point to the substring "foo", because that's our name to
define. In Forth, this is just an string+2 3 as addr len pair. In C,
you need to make a copy.
> Did you mean a completely internal substring?
Yes. You should think first and then start to babble.
> E.g., "ell" from "Hello!"? That's why C has 'n' string functions...
I don't actually think that copying a substring to make use of it is a
clever idea. You end up with all the hassles that causes C programs to
go astray: Uh, I need a buffer for that, and I need the buffer before I
know the length...
>> > If you know dest is sufficiently large
>>
>> <tourette>
>> You fucking idiot, the root cause of shitty buffer overflows is that
>> you *don't* fucking know if dest is fucking large enough!
>> </tourette>
>>
>> Do you understand now? It seems to be really hard to pass words
>> through to you.
>>
>
> Forth has the exact same issues. It affects MOVE CMOVE> CMOVE and
> all the other Forth words you listed. You keep ignoring this. So, it
> seems
> to be really hard to pass words through to you also. You now it's
> true. Just agree.
You simply don't understand the issue, and therefore I better should
stop. It's not worth the time. In Forth, you know how much MOVE will
copy *before it starts copying*, as you tell it how much it should copy.
In C, strcpy() doesn't even tell you after it did so, it is implicit.
> Ignoring the insult, that's not _exactly_ the root cause. The buffer
> size is known in C.
Unfortunately only at the point where you declare the buffer. Once you
start passing it around, this information is lost. And that's the
difference to Forth: With the recommended style of passing addr len
buffers, this information is not lost.
> Forth is no different here.
If you ignore the usual style how to deal with buffers, yes, you can do
the same bad things as in C. But in C, it's not ignoring well-
established practice, there it *is* established pratice to pass around
pointers without size as buffers.
> This is no different from not knowing the destination buffer size in
> C when you should know it and when it's available to you.
In a moderately factored C program, the buffer size is not available to
you when you need it. Because due to C's braindead "we pass buffers as
pointers, and don't tell anybody how long they are", this information
gets lost too quickly.
> So, why isn't it the programmer's job in this situation?
To fix elementary design mistakes in a language aren't the programmer's
job.
>> > Of course, you will need to make sure 'dest' is terminated, if you
>> > intend to use it as a string:
>> >
>> > dest[MAX]='\0'; /* MAX is a #define for dest's maximum size */
>>
>> Great. Yes, this is really easy to make it secure. That's why we
>> have these bugs by the 100s in large programs.
>
> How is this any different from a Forth programmer needing to keep
> track of items on the stack?
It's about easy vs. hard to find bugs. The bug above when omitting
dest[MAX]='\0'; is only a problem when you actually run in an overflow
situation. People don't test for overflows, anyways. When you get your
stack items wrong in a Forth word, it is not an occasional problem that
doesn't show up during tests, it shows up quickly.
The stack thing is like a bicycle. You have to keep balance on a
bicycle all the time. This doesn't make a bicycle a particularly crash-
prone vehicle. Your argument is about like "if you turn your wheel in
your car 60° left, at 70mph, it turns over. It doesn't turn over in all
other conditions. How is that different from a bicycle, which requires
you to balance all the time?"
The difference is that tasks you do regularly are automized by your
brain, and handled *much better* than things you don't do regularly.
>> No, the key is that there is no "sufficiently large", because the
>> attacker can always make his attack vector larger.
>
> How is Forth unaffected by this? (It's not.)
By passing the size of buffers around, and making it possible to write
correct code.
> getenv() is not standard C.
This is a rather silly argument. getenv() is both part of C89 and C99.
> Even so, it returns a pointer to a
> _string_. Any sane programmer would then check it's length via
> strlen() prior to strcpy() and strcat() to make sure it fits the
> buffer.
Unfortunately, we have only insane programmers around.
>> [...] and that it contains executable code, allowing
>> the user to gain privilege.
>>
>
> I see nothing which transfers execution to the string. In your
> example,
> it's always a string. It's possible there is a hidden buffer
> overflow, but if coded correctly, 'path' is more than long enough to
> handle the strcpy()
> and strcat().
No. You don't know if path is long enough, and the standard coding
style doesn't give you any way to even check. path may be a buffer
provided by some function above in the call tree, like
char path[60]; /* should be enough, programmer's sloppy reasoning */
tilde_expand(path, "~/.mystupidprogramrc");
> The maximum length of a system variable is known.
No.
http://stackoverflow.com/questions/1078031/what-is-the-maximum-size-of-
an-environment-variable-value
People there created surprisingly large environment variables when
trying to find the limit. It is at least operating system dependent,
and a portable program might run fine on one OS, but be vulnerable to
buffer overflows on another.
> Sorry, the allocation parameter to malloc() is known in advance.
But it is known to some completely different part of the program, which
- by conventional C style - choose to not tell anybody else.
> I don't know why you're insulting me on this issue. You've used the
> same basic argument numerous times on other issues.
I'm clearly not patient enough for a discussion with you ;-).
>> You don't know what is "sufficiently
>> large", as long as the a
>>
>
> You failed to complete your reply here.
Yes, don't know what happend. Maybe a buffer overflow ;-). You don't
know what is "sufficiently large", you are just guessing. And that's a
bad idea. There are two sane ways to deal with buffer sizes: Either
pass them along with the buffer pointer, or adjust the buffer size as
required. I prefer the latter, because it doesn't waste memory in the
typical case (short buffer sufficient), and doesn't fail, as long as
there's enough memory.
> I already told you _how_ a C
> programmer knows the buffer is sufficiently large, repeatedly. How
> does a Forth programmer know the destination buffer at 'c-addr2' is
> sufficiently large?
By checking the length which came together with the addr in an addr len
pair.
> Same reason, yes?
Not at all. Forth programs are factored to quite small entities, so
such sort of a-prior knowledge which you always insist on ("I know how
large my malloced block is"), is not useful in a Forth program.
Actually, it's also not useful in a C program, because C programs tend
to be moderately factored, too (not into the same small entities as a
Forth program, but they are still factored).
> None of the C string functions prevent buffer overflow. Buffer
> overflow is only prevent if the programmer does his/her job and makes
> the destination
> buffer large enough. That's what I've been telling you. Forth has
> the same issue.
Forth passes the size of the destination buffer around as addr len pair
- typical coding style; you can always choose to ignore conventions like
this, but that's the recommended convention.
> So, then we shouldn't be comparing MOVE or CMOVE> to any of the C
> string
> functions, should we? MOVE or CMOVE> moves memory blocks. It should
> be
> compared to the C memory functions which move memory blocks. Let's
> say memcpy() for CMOVE> and memmove() for MOVE.
Unfortunately, C strings are not memory blocks. It would be nice if
they were, because then the whole issue would quickly go away. All
strings, all buffers in C would be addr len pairs, and the knowledge of
their size wouldn't be lost.
MOVE is a low-level building block, if you want to make a buffer-to-
buffer copy (both with addr len) that doesn't overflow, you write
something like
: copy ( addr1 len1 addr2 len2 -- ) rot umin move ;
That's on the edge of becoming a word of its own, so usually, you write
that explicitely, not as a word.
[...]
>> Regardless of how you create your hash function, its key is
>> reduced to a few bits (in the order of 10), and therefore, you can
>> quickly generate a whole lot of colissions.
>>
>
> True. However, their defective implementation doesn't change their
> need for fewer collisions.
How do you know that they have too many collissions? I'm not going to
look at PHP's source code for the risk of immediate brain damage ;-).
An attacker hand-crafted a set of strings so that they would end up in a
single bucket of PHP's hash table, this doesn't indicate that they have
too many collisions in the general case.
> There are only a few ways to reduce collisions:
> increase the quantity of buckets,
Not against a deliberately chosen attack. In Gforth, we automatically
increase the number of buckets depending on how many entries there are
in the hash table, but since the algorithm is deterministic, an attacker
would still be able to create such a set of strings.
> reject adding collisions to the table,
That would violate the spec of the hash table. It stores key,value
pairs. Not adding collisions would break it.
> use different hash function, use multiple hash functions, "salts",
> etc.
IMHO the only way out is some sort of salt/xor which makes the hash
function unpredictable for the attacker. If you have a choice of 10
hash functions in such an attack, the attacker just provides one long
collision chain for each of them, and achieves his slow-down (with the
same amount of data now by a factor of 10 less).
> If they continue to limit the number of buckets, the original cause of
> their problem
> remains. According to you, they fixed the "effect" of the problem
> instead of fixing the "cause" of it.
Yes. Well, you can argue that an attacker who is allowed to fill in
arbitrary values in a globally used table in PHP is a problem in any
case, so removing that capability (which apparently didn't break
programs) is a good idea.
>> > I'm not sure if these are the type of hash functions they need, but
>> > these two public hash functions are good:
>> >
>> > Austin Appleby's MurmurHash2
>> > Bob Jenkins' hashlittle() from lookup3.c
>>
>> hashlittle() is perfect to use for lookups, but it does nothing to
>> prevent this attack.
>
> These two have far fewer collisions than other hash functions I
> checked.
All reasonable hash functions pass a chi² test on non-random data (e.g.
a dictionary), and should have about the same number of collisions.
That's how you test if your hash function is good.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-02 16:28 -0700 |
| Subject | Re: Function Points |
| Message-ID | <7x7gscngw5.fsf@ruckus.brouhaha.com> |
| In reply to | #15404 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > I don't actually think that copying a substring to make use of it is a > clever idea. You end up with all the hassles that causes C programs to > go astray: Uh, I need a buffer for that, and I need the buffer before I > know the length... To defend C a little bit, it was designed in an era when memory bytes were more valuable than now, and malicious input was far less of a consideration. Programs didn't back then didn't usually interact with an internet full of hostile strangers. Passing extra parameters to C functions is less of a stylistic problem than passing them to Forth functions too, since they are directly accessible without resorting to stack juggling or add-on locals. These days, because C was so pervasive in the past, it's still used in places where it probably shouldn't be.
[toc] | [prev] | [next] | [standalone]
Page 5 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