Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Counted string Date: Mon, 26 Jan 2015 21:55:01 -0500 Organization: Aioe.org NNTP Server Lines: 72 Message-ID: References: <174b22de-2454-4e17-ac18-6a1333ec408f@googlegroups.com> NNTP-Posting-Host: i+Urkql2cL38hhKqzSWEjg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:36064 On Mon, 26 Jan 2015 15:14:09 -0500, Pablo Hugo Reda = wrote: > El lunes, 26 de enero de 2015, 16:21:52 (UTC-3), Marek Brunda escribi= =F3: >> Dne sobota 24. ledna 2015 2:17:25 UTC+1 Rod Pemberton napsal(a): >> > On Mon, 19 Jan 2015 02:54:49 -0500, Marek Brunda >> > wrote: >> > > Hi, can anyone explain me, what's wrong with counted strings? May= be = >> it's >> > > a stupid question, but I've never understood it. Thanks >> > >> > This has been discussed many times here in the past. >> > You can search the Google Groups archive of this Usenet group. >> > >> > Nul-terminated strings replaced counted strings for the most part >> > many decades ago in most programming languages, e.g., 1970's or = >> 1980's. >> > >> > The problem back then with counted strings was that the count could= >> > be changed, but the length of the string wouldn't be. I.e., there >> > is a mismatch in the size of the count and the actual length of the= >> > string. If the count is too short, then the string is truncated. >> > This isn't a problem. If the count is too large, then you have a >> > very serious issue. More space for a new larger string wasn't >> > allocated. The string is the same size, but the count is larger. >> > So, the oversized count value allows you to access data PAST the >> > actual end-of-string. I.e., you can read data you shouldn't have >> > access to, or write to variables you shouldn't have access to. >> > This is the same technique used by hackers for buffer overflow. >> > >> > (FYI, to prevent flame war, there are those here who claim that >> > can't actually happen in Forth ...) >> > >> > Languages like C which use nul-terminated strings frequently >> > only need to detect the end-of-string. They generally don't >> > need to know the string's length. So, not counting the length >> > of a string and just appending a nul-terminator to create a >> > string increased code speed. Of course, not terminating >> > a string in C, which happens with some string functions under >> > certain conditions, can cause overruns or unintended access too. >> > >> >> I read all the posts and I understand the arguments. So why not use = >> NULL terminated strings in Forth? > > some forth use null terminate strings !! mine is one I use nul-terminated, C-compatible strings in my Forth too. 2/3 of it passes Hayes Core. Mostly, the floating point and a few odd words remain from ANS "core" and "core ext". It's coded in C. It fails one Hayes Core test for strings. This is due to the way the test constructs strings. It makes an assumption about the implementation. This can be fixed by providing an extra, unused byte at the beginning for the length field that the tests expect. Although, I haven't done so yet. So, there isn't much of a reason to not use them, AFAICT so far. Most of the mechanics of forth strings are hidden behind a few words and don't affect the user or programmer. I.e., they can be changed to use other string representations. Rod Pemberton