Mail Archives: djgpp/2013/06/18/11:00:13
Hi,
FYI, I've not tried compiling your code (yet), nor am I really
familiar with strtok(), but anyways .... (BTW, Google Groups is
especially horrible here, I don't know why they don't fix it.)
http://en.cppreference.com/w/c/string/byte/strtok
On Tuesday, June 18, 2013 3:26:10 AM UTC-5, K.J.Williams wrote:
> On Monday, June 17, 2013 3:48:36 PM UTC-7, Rod Pemberton wrote:
>
> > "K.J.Williams" <nospam AT nospam DOT no> wrote in message
>
> > news:36e857f0-9899-496b-9fc6-32251e109888 AT googlegroups DOT com...
>
> But the problem is that DJGPP will not warn me about violating
> memory boundaries with the parstext.c program as it does with the
> bigger program WATT ( a project of several files ). I wanted to know
> why isn't DJGPP warning me when I run parstext.c runs without complaints?
> Its basically a segmented memory violation caused by strtok on following
> calls.
You probably just got lucky or the error was masked. You did say you
were running under plain MS-DOS 7, right?
> I have debugged my program using printf statements and commenting out
> parts of my program to follow the source of the error was in my
> string_parser() function which is not implementing strtok() as it
> should be , defined by the C standard ( which was not clear to me at first ).
If your WATT gives you SIGSEGV, try running it under GDB and doing a
backtrace ("bt"), if possible. Or run bfdsymify.
> I am actually using cprintf() in my bigger program and printf() in
> my smaller program - with respect to the differences that one uses
> stdout, and the other uses direct BIOS calls to the video.
Yeah, I figured that much when I saw "\r\n" in there. Normally you'd
never do that, it's done behind the scenes, but non-standard
conio requires it.
> Remind me again, is DOS newline : "\r\l" or "\r\n" ???
Most DOS calls assume CR (carriage return) plus LF (linefeed), aka 0xD 0xA.
That basically means "\r\n" (for conio), but for normal stdio, you don't
(and shouldn't) probably use that, only plain "\n". It's translated
behind the scenes for you.
And just for clarity, I'm fairly noobish myself, but I didn't remember
any "\l" escapes. A quick check at the URL below doesn't list one, so
don't use that (or you'll probably get a literal "l", which isn't
what you want).
http://www.dummies.com/how-to/content/c-language-escape-sequences.html
BTW, I once rented _C in a Nutshell_ from the library (few years ago).
It looked pretty exhaustive for C99 and IIRC had a simple example
program for every libc function. (Normally I hate recommending books,
they usually don't help or are too expensive, but here it may help.
Besides, like I said, my library had it, so it didn't require blind
purchasing just to glance a bit. Amazon users overall gave it 4.4
out of 5 stars, so it seems to be widely respected.)
> yes, the forum of www.cprogramming.com for their c programming section
> drummed this point over and over in my posts their. Part of my confusion
> was with how I understood the C standard of strtok() defined in C99
Well, strtok() existed well before C99. It's in C89 too. But yeah,
most people ignore older standards.
> > Two characters for newline under DOS ( '\r\n') would require stdin
> > to be set to binary mode. Off hand, I don't recall if stdin is
> > set to binary mode or text mode, but I suspect it's text since I
> > generally use binary mode and check for two... I.e., one
> > character ('\n') is all I think you should need to get.
No, IIRC default isn't binary mode because that would disable Ctrl-C
and friends. I don't know what default is called, "cooked" (vs. "raw")??
> I thought that since DJGPP is a port of GCC, which is from a Linux ( Unix )
> environment , all modes in file reading are binary regardless if they are
> reading or writing - so I thought that GCC was imported with that
> strict implementation.
Nope. While there's a lot of sloppy code out there (*nix) that assumes
it's the same as binary, it's not. You have to explicitly setmode()
or assign something to _fmode (for open) or fopen(...,"rb") or some
other weird gobbledegook.
Usually you won't set the console to binary unless doing something
(e.g. compression of binary data) between stdin / stdout.
> And again, I know that a newline feed
> in Linux is '\l' but I am not sure for DOS , if its "\r\l" or "\r\n" ..???
The DOS kernel API usually assumes CR+LF. DOS binaries can accept both
if properly designed (but most don't, esp. older ones). DJGPP does it
behind the scenes, so if you use stdio like printf(), you don't have to
worry, just use '\n' everywhere (unless doing something really weird).
> I am developing a scripting language which will interpret ASCII text
> files in MS-DOS to execute created console programs , in a modified
> MS-DOS environment that is booted up from a USB flash drive. This is
> similar how fedora core OS can be booted up on a USB flash drive
> without a hard drive.
I know it's off-topic, but DOS can boot from USB too. See RUFUS:
http://rufus.akeo.ie/
> My main program called WATT... uses a command line interface the
> same way that GCC or any other command line program interprets ....
>
> When it runs my program , it copies one text line either containing my
> scripting language commands or text to do whatever depending on what
> has been told to the interpreter....
I have some interest in scripting languages too, but writing one is
a whole extra heap of difficulty. In particular, grammars and parsers
are often (over)complicated. I'm surprised nobody told you the
(semi-useless) advice of "just use YACC/LEX". Lots of books cover
all of this, even some YouTube videos, but it's far from easy (heavy
understatement!).
I suggest you look at what others have done. Check their sources, see
how they parse things. I would personally suggest to look at Regina
Rexx or Lua (both written in C, both with DJGPP ports), but various
others could work too.
http://regina-rexx.sourceforge.net/
http://www.lua.org/
Actually, I'd really suggest looking up various esolangs, they are
much stupider and simpler and easy to parse. Once you get your feet
wet with those, you can go on to (hopefully) create more complicated
stuff.
http://esolangs.org/wiki/Main_Page
- Raw text -