Date: Mon, 21 Dec 1998 00:49:05 -0800 From: Mike Smith <mike@smith.net.au> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: current@FreeBSD.ORG Subject: Re: BootFORTH - demo floppy Message-ID: <199812210849.AAA50785@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 21 Dec 1998 00:41:02 PST." <199812210841.AAA07194@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> At Sun, 20 Dec 1998 16:23:48 -0800, you wrote > >> > >> 2) Could someone please add the 30-years old traditional > >> "ok<newline>" prompt in interpreting mode? > > > >The prompt is fully configurable; set it yourself if that's what you > >want. > > Ok. I did not know the prompt was configurable. 'help set prompt' then 'set prompt=ok\n' should do it. > >> 3) I noticed "evaluate" is working with null-ended string, ignoring > >> completely the count on the stack. Not good. > > > >Is this an implementation feature? Does the count on the stack ever > >not match the length of the string? > > I'm not sure what do you mean with the first question. As for the second > question... sure. Forth string operators are all count based. The null will > not appear on the end of the string unless you put it there yourself. We don't like counted strings. They suck for innumerable reasons, and if the only reason for having them there is "tradition" (ie. there is no reason *not* to take them away) then they can damn well die. 8) Having said that, I get the distinct impression that we're stuck with these deadweights. > Now, adding nulls to the end of the string is very easy with count based > strings (as long as you are not working with a substring), and I have nothing > against doing it. But having "evaluate" operate on null-terminated strings is > the same as having strncmp operate on null-terminated strings: it's against > standard and intent. That's something you're welcome to take up with Mr Ficl; bear in mind though that we're talking about something that has to work fairly close to a much more significant C application. If trading between the two formats is a good idea from the efficiency point of view, that's probably the way to go. If you have any more concrete reasons (like it breaks something significant), then that's something I'd be happy to address, but "it's not normally done like that" is perhaps less important than "it's easy to work with in this context". -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812210849.AAA50785>