#: 13841 S3/Languages
    05-Jan-92  11:41:18
Sb: #Help
Fm: George Hendrickson 71071,2003
To: all
Can someone direct me to the C compiler development package, or whatever that
has 'rlink' and 'rma' in it? I recently bought the C compiler and wanted to do
a little upgrading. Thanks.
There is 1 Reply.

#: 13849 S3/Languages
    05-Jan-92  17:45:12
Sb: #13841-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)
George -
That's the Developer's Pack, and I understand it's hard as hen's teeth to come
by these days.
Pete

#: 13862 S3/Languages
    06-Jan-92  03:04:55
Sb: #Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
How do I get it? I want to get into some C programming so I can bug you guys
with programming problems!! :-)
There is 1 Reply.

#: 13867 S3/Languages
    06-Jan-92  09:00:12
Sb: #13862-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003
George -
I guess you could see if RS still carries it in their express software special
order listings ($99). A general request here me also help, as some folks are
unloading their stuff and moving on to MM/1's, PC's, etc.
Pete

#: 13891 S3/Languages
    06-Jan-92  23:28:09
Sb: #problems with c files
Fm: BRUCE BAKER 73747,3137
To: all
Sb: problems with c files Fm: Bruce Baker 73747,3137 To: all
I recently dowmloaded "CC.AR" and a bunch of other C files, including the whole
"mlib" set (sqrt.c,pow.c,etc.) and much to my dismay, I found that they
wouldn't compile for me. I just got the C-compiler from express order (Radio
Shack) and the Rainbow Guide c files and a few that I've written compile
perfectly. My compiler disk didn't come with "cc2", so I was really hoping to
get the cc.ar package up and running. What, if any, problems will I run into by
using the c-compiler package on my 512k level II system? Where does one get the
"cc2" (I'm still trying to track that down by phone with R.S.)?
There is 1 Reply.

#: 13914 S3/Languages
    07-Jan-92  09:25:04
Sb: #13891-#problems with c files
Fm: Pete Lyall 76703,4230
To: BRUCE BAKER 73747,3137 (X)
Bruce -
Your compiler will work fairly fine out of the box... CC2 was a level II
version of CC1 that MW used to distribute. The biggest difference was that it
called 'c.comp' instead of 'c.pass1' and 'c.pass2'. C.comp was a one pass
compiler that was too big to fit in a level I address space, thus C.pass1 and
C.pass2 were developed for the smaller LI machines. The LI stuff (Tandy's) will
run fine under LII.
The CC.AR package is a good add-on, and you should see about what you need to
get it to compile. My bet is you need the KREIDER library replacement. In a
nutshelll, Carl Kreider rewrote the entire library in assembly for speed and
bug removal. There are also some addon functions, and the whole thing was well
documented. Best bet here is to go over to DL3 and pickup the kreider lib
stuff.
Pete
There is 1 Reply.

#: 13920 S3/Languages
    07-Jan-92  16:20:01
Sb: #13914-problems with c files
Fm: BRUCE BAKER 73747,3137
To: Pete Lyall 76703,4230 (X)
Thanks. I called Tandy software support today, and was told that they never
bought the level II stuff from Microware. I got the Kreider lib last night.
I'll get the docs soon.
  I'm taking a C programming course this semester at Red Rocks Community
College here in Denver. I hope that you'll be hearing a LOT from me soon!

#: 14094 S3/Languages
    27-Jan-92  10:57:10
Sb: #13867-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
Yeah, I ordered the C compiler from RS and they gave me the disks but not
book!! I don't know if I got it all or what! I've been having trouble compiling
a few things cause I don't have the file 'string.h' or 'strings.h'. Do you know
where I can get them? I know that most everyone is moving on to bigger things.
I hoping to buy a 386 this spring. I've been looking at some 40 mhz systems
that have had me drooling over them!<grin> It would be great if the CoCo ran
that fast! Imagine that! Thanks for you help.
There are 2 Replies.

#: 14096 S3/Languages
    27-Jan-92  14:39:27
Sb: #14094-#Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)
George -
I always get this mixed up, but in UNIX land, System V uses either string.h or
strings.h, and Berkeley uses the other one.
You should be able to get all the .h files you need by downloading Carl
Kreider's C Library replacement stuff. Browse over in DL3.
Yell for any help you need - that's why we iz here. Also, beat on Rat Shack
until they produce a book for you. Won't help you with C, but will give you
some compiler poop to mull over.
Pete
There is 1 Reply.

#: 14102 S3/Languages
    28-Jan-92  03:29:04
Sb: #14096-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
Thanks for the help. I finally find the header files I need after replying to
the previous message. I must have missed it before or something. (who knows
what happens at 4:30am??) Now I need to find the RMA file for the CC program.
I'll probably find after I leave this but just in case, do you know the file I
need to get by chance? Rat Shack finally gave up on the book so I bought 'Teach
Yourself C' by Herbert Schildt. Its pretty much informative and shows some
great examples of stuff. Welp, I'm off!
There is 1 Reply.

#: 14105 S3/Languages
    28-Jan-92  09:03:59
Sb: #14102-#Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)
George -
Under the RS version of the Level 1 C Compiler (works fine on L2, BTW), RMA =
C.ASM and RLINK = C.LINK.
Pete
There is 1 Reply.

#: 14118 S3/Languages
    30-Jan-92  03:04:24
Sb: #14105-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
I don't know what level version I have of the C Compiler other than it being
version 1 (c)1983. It didn't have the files RMA or RLINK in it. I did find a
patch file for RMA and RLINK here. I tried them out on c.asm and c.link and it
didn't work. Do I have all the files that I need? Or should I just give up and
buy a new computer that has tons of software available?
There is 1 Reply.

#: 14121 S3/Languages
    30-Jan-92  08:50:26
Sb: #14118-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003
George -
Easy, pal...... let's get the facts foist:
What DO you have on the disk? To my knowledge, the ONLY C compiler R/S ever
sold for OS9 was the LI coco version, and it used C.link, and C.asm. There was
an UPDATE to these later on the LII Developer's Kit that offered RMA and RLINK.
Send a directory of your disk and we'll take it from there. Remember when you
store the message here to use 'SU' (store unformatted), or the CIS editor will
mung it as it sees fit.
Pete

#: 14097 S3/Languages
    27-Jan-92  14:41:36
Sb: #14094-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)
Yep - just checked. Nab HEADER.AR in DL3. That should do it.
Pete

#: 14188 S3/Languages
    04-Feb-92  03:21:19
Sb: #14121-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
Welp, here's my Compiler disk CMDS directory:
cc1      c.prep     c.pass1      c.pass2 c.opt    c.asm      c.link       copy
del      dir        echo         list
Here's the Library disk they gave me:
LIB directory
clib.l    cstart.r
DEFS directory
ctype.h   direct.h   errno.h   modes.h module.h  os9.h      os9defs.a setjmp.h
sgstat.h  signal.h   stdio.h   time.h
SOURCES directory
SYS        line.c     prof.c     rdump.c
SOURCES/SYS directory
abort.a       access.a      cfinish.a     change.a comp.sys      cstart.a     
dir.a         id.a intercept.a   io.a          make.sys      mem.a misc.a
mod.a         process.a     profdummy.a signal.a      stat.a        syscall.a
syscommon.a tidyup.a      time.a
That's what they gave me. They said they couldn't get the books for it. Can you
tell me what I have? Is there a C editor around somewhere or do I just use the
ol' wordprocessor?
There is 1 Reply.

#: 14190 S3/Languages
    04-Feb-92  08:36:07
Sb: #14188-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003
George -
It looks complete to me. There is no C editor... You just use whatever text
editor you're comfy with. I used to use Dynastar.
In addition to there being replacement libraries, there's also a replacement
'CC' command here. That may help some with the documentation. Also, if you have
a RAMDISK set up, the new CC will use it for a scratch area, and that will make
compiles a LOT quicker.
Pete

#: 14357 S3/Languages
    16-Feb-92  23:20:53
Sb: #Cenv.ar
Fm: Paul Rinear 73757,1413
To: Anyone
   I downloaded 'cenv.ar' and unar'ed it. The documentation is further
   encoded and I can't figure out how to decode it. Has anyone been
   sucessful decoding this?
                               Paul
There is 1 Reply.

#: 14370 S3/Languages
    17-Feb-92  21:22:55
Sb: #14357-#Cenv.ar
Fm: Brother Jeremy, CSJW 76477,142
To: Paul Rinear 73757,1413 (X)
You need to use a program called CUTS. It is an encoder/decoder for use on the
UUCP networks. (I Think) It sould be here on CIS. Just
 browse for CUTS in the databases.
Br. Jeremy, CSJW
There is 1 Reply.

#: 14380 S3/Languages
    18-Feb-92  15:11:38
Sb: #14370-Cenv.ar
Fm: Paul Rinear 73757,1413
To: Brother Jeremy, CSJW 76477,142 (X)
  Thanks. Will look around for it.

#: 14412 S3/Languages
    23-Feb-92  12:25:15
Sb: #14190-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
I think I tried CC but it need RMA and RLINK which I don't have. Where do I get
those files?
There is 1 Reply.

#: 14415 S3/Languages
    23-Feb-92  15:41:39
Sb: #14412-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003
George -
RMA and RLINK come on the DEVELOPERS PAK disks. Technically, you could use a
disk editor and patch the module names of C.asm and C.link to be RMA and RLINK.
Then you would of course also have to rename the files to the same names.
Optionally, you could get the developers pak.
Pete

#: 14571 S3/Languages
    10-Mar-92  20:24:43
Sb: #C.LINK problems
Fm: GENE TURNBOW 72457,220
To: ALL
I have a problem that I'm hoping somebody here can help with.  I'm running the
Microware C compiler under OS-9 LII, and have problems linking with multiple
libraries.  The linker (c.link) reports my libraries as being made up of
non-relocatable code.  How do I get by this to get a good compile outa the damn
thing?  Any help would be appreciated.
There is 1 Reply.

#: 14575 S3/Languages
    11-Mar-92  00:41:20
Sb: #14571-#C.LINK problems
Fm: Pete Lyall 76703,4230
To: GENE TURNBOW 72457,220 (X)
Gene -
Hmm.... it may be that the libraries you have were generated using the newer
versions of C.ASM (now RMA) and C.LINK (now RLINK). If that's the case, then
there's an extra integer in each module and the older versions won't know how
to handle it. Possible solutions:
  a) Get the newer versions of RMA/RLINK from the Os9 LII Developers Pak
  b) Get older versions of the libraries (I _think_ the Kreider libs
     are still produced using the older C.asm/C.link for backwards
     compatibility reasons. The RMA/RLINK pair will handle the older
     libraries).
Pete
There is 1 Reply.

#: 14579 S3/Languages
    11-Mar-92  21:38:52
Sb: #14575-C.LINK problems
Fm: GENE TURNBOW 72457,220
To: Pete Lyall 76703,4230 (X)
That has to be it.  I do have the Developer's Pak, and I know that they can be
used instead of c.asm and c.link and that my 'cc' (I downloaded from CIS,
actually) can be adjusted to use them.  I'll try that next.  Thanks! This helps
a great deal.

#: 14697 S3/Languages
    26-Mar-92  02:48:09
Sb: #14415-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
Where can I get the Development package? I just recently bought a 386DX and
I've got Turbo C++ that I've been tinkering with. I'm starting to get the hang
of C so I'll probably start writing some stuff for the CoCo in C before you
know it!
There is 1 Reply.

#: 14699 S3/Languages
    26-Mar-92  09:28:46
Sb: #14697-Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003
George -
Last I heard, you have to order it from the RS special order software catalog.
A better bet would be to find someone who is selling their coco3/2 and try to
snag a used one.
Pete

#: 14724 S3/Languages
    30-Mar-92  10:15:10
Sb: #getkey problem in C
Fm: Robert A. Hengstebeck 76417,2751
To: all
Can someone help this poor frustrated fellow.  I've been trying to get
a value returned from my getkey function to my main function, and I
have tried many ideas starting with using a 'return()' in the getkey.
I am getting the correct value from the 'printf' statement within the
getkey function, but when I print the value from the main function, I
consistently get some number like 19802 for both 'j' and 'vlu'.  So
it seems that nothing is getting back up, unless the new value is a
pointer to the returned value - just a wild guess.  The following
is a listing of what I have ended up after many trials.  What do
you suggest?
   ** program name 'hello/c' **
  #include <stdio/h>
  #option INLIB
  int j, vlu;
    main()
    {
     int i;
     int getkey();
     void clearsc();
     void gotoxy();
         clearsc();
         printf("Enter a key when you are ready\n\n");
         getkey(vlu);
         j = vlu;
         printf("vlu answer is %d,  j answer is %d \n\n",vlu,j);
    /*    for(i = 0; i < j; i++)
           {
             gotoxy(i*2,i);
             printf("This is my first program\n");
           }                                             */
    }
    void clearsc()
    {
         fputs("\x1c\x1f",stdout);
    }
    void gotoxy(col,row)
    int col,row;
    {
        cursor(col,row);
    }
    int getkey(vlu)
    {
        while (TRUE)
        {
            vlu = inkey();
            if (vlu != 0)
                break;
        }
        printf(" the answer here is %d \n\n", vlu);
    }
    This program is being programmed on a Model IV computer, so if
    there are any peculiarities, I have tried to avoid them.  If I
    seem to be making some silly code, please forgive me, since its
    been three years since I last wrote in C.
There is 1 Reply.

#: 14729 S3/Languages
    30-Mar-92  21:36:00
Sb: #14724-getkey problem in C
Fm: Bob van der Poel 76510,2203
To: Robert A. Hengstebeck 76417,2751
Bob,
Change the call to getkey() from getkey(vlu) to vlu=getkey(). Then change
getkey() to:
    int getkey()
    {
        int v;
        while ((v=inkey())==0);
        return v;
    } Hope this helps.

#: 14733 S3/Languages
    31-Mar-92  02:14:38
Sb: #14699-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
Do you know the catalog number for the development package? There isn't anyone
I know that has a CoCo for sale anymore. All my friends went to MSDOS a few
years ago. There's only one other guy in my area that has a CoCo and he runs a
BBS on his also. He's still using RSDOS though.
There are 2 Replies.

#: 14736 S3/Languages
    31-Mar-92  03:01:21
Sb: #14733-#Help
Fm: Pete Lyall 76703,4230
To: George Hendrickson 71071,2003 (X)
George -
Sorry.. no idea. Got any old (2 yrs) RS catalogs around?
Pete
There is 1 Reply.

#: 14771 S3/Languages
    03-Apr-92  10:56:13
Sb: #14736-#Help
Fm: George Hendrickson 71071,2003
To: Pete Lyall 76703,4230 (X)
Geezzz.. I don't know...I'll have to look.... I'm starting to have other
problems now. I think my GIME chip has gone bad. The computer just locks up
every now and then and starts printing those sparklies on the screen. I can't
run my Burke & Burke File Repack System anymore. As soon as I type 'repack /h0'
the program will load and the drive light will come on for a second and then
nothing or the sparklies come back. Even multitasking seems to not work right
sometimes. My Deskmate wordprocessor doesn't work right either when I try to
copy blocks pf text. I figure, well it might be the GIME chip as I've heard
that when they go bad, things like that happen. It most likely is as I have
been running my CoCo for about 5 years nonstop now running a BBS. I've alreay
had to replace a HD a couple of years ago. Where can I get updated GIME chip?
Does Frank Hogg have them? Thanks...
There is 1 Reply.

#: 14777 S3/Languages
    03-Apr-92  16:00:42
Sb: #14771-#Help
Fm: Kevin Darling 76703,4227
To: George Hendrickson 71071,2003 (X)
George - try cleaning the GIME chip contacts... or at least tapping on it. Same
for the MPI connectors (if you have one).  It's amazing how cruddy the metal
gets, especially after some moist days.
There is 1 Reply.

#: 14783 S3/Languages
    04-Apr-92  02:43:14
Sb: #14777-#Help
Fm: George Hendrickson 71071,2003
To: Kevin Darling 76703,4227 (X)
I cleaned all my connections with a Nintendo cleaning kit. Those suckers were
filthy! Especially slot 4 on my multi-pak! I'm still using an old Radio Shack
floppy drive controller. I would like a nice Disto controller if I can find
one. To clean the GIME chip contacts, should I pull the chip out and clean them
or will some type of cleaner work like a Zero residue spray? BTW, I still got
the same results with 'repack' after I cleaned my connections. I hope cleaning
the GIME chip connections will make it work... Thanks for the help...
There is 1 Reply.

#: 14784 S3/Languages
    04-Apr-92  04:59:20
Sb: #14783-Help
Fm: Kevin Darling 76703,4227
To: George Hendrickson 71071,2003
I usually just pop the GIME out, and then pop it back in again... seems to be
enough to cure a lot of ills (too lazy to spray it off so far :).
You might call CRC and see if they have any Disto controllers left.  Tony was
making a few more, and there was a false report on the nets that they were all
gone.  Actually, the CRC salespeople goofed and didn't catch on that there were
going to be a few more made available.
Same goes for 1-meg upgrades and the 4-in-1 boards, I think.
luck!- kev

#: 14741 S3/Languages
    31-Mar-92  19:19:45
Sb: #14733-#Help
Fm: Bill Dickhaus 70325,523
To: George Hendrickson 71071,2003 (X)
According to the manual I got with the development system, the catalog # was
26-3032. From what I've heard over on Delphi, you might be able to find one,
but it won't be easy.
Bill
There is 1 Reply.

#: 14773 S3/Languages
    03-Apr-92  11:01:27
Sb: #14741-Help
Fm: George Hendrickson 71071,2003
To: Bill Dickhaus 70325,523 (X)
Thanks. I'll check with my local Radio Shack this weekend and see if they can
help me.

#: 14735 S3/Languages
    31-Mar-92  02:58:27
Sb: #14724-#getkey problem in C
Fm: Pete Lyall 76703,4230
To: Robert A. Hengstebeck 76417,2751 (X)
The problem seems to be that you're passing 'vlu' to getkey() by VALUE... that
is, you're sending a clone of VLU, but not VLU itself.
In order to do what you want, you weel need to pass a pointer to VLU, ala:
     getkey(&vlu)
and then down in getkey() (note declaration of vlu):
 int getkey(vlu)
 int *vlu;
        {
        *vlu = inkey();
         ....
        }
Pete
There is 1 Reply.

#: 14747 S3/Languages
    01-Apr-92  06:47:02
Sb: #14735-#getkey problem in C
Fm: Robert A. Hengstebeck 76417,2751
To: Pete Lyall 76703,4230 (X)
Pete, your way of returning the pointer to the entered value, turned out to be
be the best approach to what I was trying to do.  I changed the 'int getkey()'
to a 'char getkey()' also, since I found that I could more easily handle the
returned value than the clone.
There is 1 Reply.

#: 14748 S3/Languages
    01-Apr-92  09:50:47
Sb: #14747-getkey problem in C
Fm: Pete Lyall 76703,4230
To: Robert A. Hengstebeck 76417,2751 (X)
Actually, 'C' (or really C++) is bending in your direction...
In C++, you can pass variables by reference without using pointers:
   swap(a,b)
    .....
   swap( int& a, int& b)
        {
        int temp;
        temp = a;
        a = b;
        b = temp;
        }
There are a few nice things about this approach:
   1) You no longer have to dereference pointers
   2) It is more intuitive in the target function
   3) Because you're not using pointers, you have no
      opportunity to walk on something else.
I believe there's a GNU C++ for the OSK boxes...
Pete

#: 14746 S3/Languages
    01-Apr-92  06:43:19
Sb: #14729-getkey problem in C
Fm: Robert A. Hengstebeck 76417,2751
To: Bob van der Poel 76510,2203 (X)
Thanks Bob, I like your 'while' loop better than the one that I had.  But also
see my message to Pete.

#: 16037 S3/Languages
    26-Jul-92  17:39:14
Sb: #need a compiler
Fm: james gross 76417,317
To: all
To All,
Help, can you suggest several C compilers that are compatiable with os9. I must
choose a compiler for a 68010 project. I would like to look at at at least 5
different ones.
Thanks, J. Gross
There is 1 Reply.

#: 16073 S3/Languages
    29-Jul-92  23:07:57
Sb: #16037-#need a compiler
Fm: Bob Palmer 74646,2156
To: james gross 76417,317
The only two OS9 compilers for 680x0's that I have seen are (1) the standard
Microware C Compiler and (2) the GNU C compiler.  One is commercial, the other
has the GNU group baggage which you may not want.  GNU C produces faster code
than the Microware standard (at least in my limited experience) and handles
UNIX source a little better.  I doubt very much that you will find any other
OS9 compatible compilers because of the need for special headers etc. Bob
There is 1 Reply.

#: 16074 S3/Languages
    30-Jul-92  01:11:34
Sb: #16073-need a compiler
Fm: Mike Haaland 72300,1433
To: Bob Palmer 74646,2156
Not only that, but the GNU C compiler for OSK needs the Microware linker and
assembler.  So...  There is really only 1 package.   GNU C does output faster
assembler code, at least that's what I hear.
 - Mike -

#: 16294 S3/Languages
    25-Aug-92  13:20:48
Sb: #Your July article
Fm: Mark Griffith 76070,41
To: Bob van der Poel, 76510,2203 (X)
Bob,
I take exception to something you say in your article in the July Issue of the
OS9 Underground.  In there, you list a header file that defines the malloc(),
calloc(), and several other functions dealing with memory management as 'void
*malloc', 'void *calloc', etc.
This is completely contrary to the ANSI and K&R standards.  These functions do
indeed return a value, namely a pointer.  To define them as type void is not
only dangerous to the program development since it will cause the compiler to
leave items on the stack, but it is especially poor when used in an article
that proports to be a 'teaching' series.
I see you mention you do this to keep the compiler happy when you assing
..errr...assign any form of return value to a pointer.  I know of no need to
ever do this, and have never seen this feature (or bug' documented any where.
I think a retraction and correction in the next article is in order.
Mark
There is 1 Reply.

#: 16296 S3/Languages
    25-Aug-92  14:43:13
Sb: #16294-#Your July article
Fm: Mike Haaland 72300,1433
To: Mark Griffith 76070,41 (X)
Mark,
In the UNIX System V, Release 4, they have made malloc(), calloc() and many of
the memory functions that return pointers all type void *.  Check out memory.h
and malloc.h on one of the Unix boxes at work.
I don't know if his reasons are 'kosher', but he's right on the defines.
 - Mike -
There is 1 Reply.

#: 16297 S3/Languages
    25-Aug-92  17:33:39
Sb: #16296-#Your July article
Fm: Mark Griffith 76070,41
To: Mike Haaland 72300,1433 (X)
Mike,
Well, if we were talking about System V here, then maybe I'd be less concerned.
However, were are talking about OSK I believe.  I have looked at my headers
here are work (SunOS 4.1.2) and malloc and the rest are of type char *.
A type void pointer is a pointer that can later be declared to point to any
object.  In the case of 'void *ptr', this would still be confusing to the new C
programmer, but legal in several compilers.  That pointer can then be defined
as any type of pointer.  Why one would want to do this instead of declaring it
to be what it will be used for is beyond me.  I suppose someone might want to
do that to fool around with some byte size ordering or something of that
nature....surely something that is mnot easily portable or readable.
However, the malloc() and like functions do return a pointer of the character
type.  Trying to declare that as something else later would to me make it
entirely too difficult.  Even if OSK supported this, and that is the
questionable part, I would hesitate to use it in a 'teaching' environment.  In
any case, explaining the use as 'so the compiler won't complain' is not what I
would call the best method.
If someone is going to take it upon themselves to act in a teaching role, then
they also take it upon themselves to have their 'product' as squeeky clean and
bug free as humanly possible.  There is no excuse for anything less.  Take it
from someone who has taught subjects such as this at the junior college
level....you have to pass the strictes scrutany (if course, I can spell the
words I want to use to make my point).
My point, in a nutshell, is Bob is working in areas outside the scope of the
OSK/OS-9 compilers, his explainations are lacking, and this can mislead those
people that are reading it and don't know any better.  It should be in context
and clearer.
Mark
There are 3 Replies.

#: 16299 S3/Languages
    25-Aug-92  21:54:05
Sb: #16297-Your July article
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)
I probably shouldn't even bother to reply to your message. After all, you've
already decided that I'm wrong and you're right. On the other hand, I guess I'm
in pretty good company now--not everyone has the privilege of getting flamed by
you. Frankly, Mark, you really should read your messages over before posting
them and attempt to be a bit more charitable in your comments to others.
Weren't you the one offering to send folks a Bible awhile ago?
Also, I find it strange that you take exception to Mike's comments about it
"being correct in Unix" not applying when it comes to OSK. Heck, every time
someone wants to do something different, you get on your soapbox and wail about
the "unix standards" already in place and how we should follow them. Oh well.
If you care to check an ANSI C reference, you'll find that malloc(), etc are to
be defined in <stdlib.h> as returning pointers of type VOID. Since OSK doesn't
use <stdlib.h> I took your advice and used the unix standard of having a
<malloc.h> header. It'd be fine to declare malloc(), etc as returning a ptr to
char, but then you have to do an explicit cast to use it as anything else. Just
checked the MW manual, and it does list char *malloc(). So, maybe you're right
and I'm wrong. Maybe I'm a lousy teacher. At least I teach and share what I
learn.
If it's that important to you, why don't _you_ write an article and explain
your thinking. And while you're at it, tell the folks where declarations for
malloc(), etc belong (maybe check the unix standard?) and the best declaration.
But do keep in mind the new ANSI standards, compilers like GNU, portability,
what works best, and what other professionals are using. Should make for
interesting reading--I look forward to it.

#: 16300 S3/Languages
    25-Aug-92  21:55:00
Sb: #16297-#Your July article
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)
Reading over the last message, I find myself falling into the same nasty habits
I accuse you of. Sorry. However, I'm still a bit upset at you, Mark, since I
never did receive the keyboard adaptor for my MM/1 you promised to send me
about 8 months ago. I've sort of stopped checking the mailbox for it...
On to keeping the compiler happy. Have a look at the following code:
 extern void *malloc();
 foo()
 {
        char *char_p;
        unsigned char *u_char_p;
        u_char_p=malloc(100);
        char_p=malloc(100);
 } This will generate a pointer mismatch for the 'u_char_p=' line. The compiler
is correct in this warning. However, changing the declaration of malloc() to
void "solves" the problem.
Yes, I know the "correct" non-ansi method of doing this is to explicity cast
the return value of malloc to the needed type. However, these casts tend to
obscure code even more--and this is one of the reasons ANSI developed the void
pointer.
Also, your comment about the compiler leaving stuff on the stack due to a void
declaration is just plain wrong!
And if only perfection is permitted in teaching, then we better empty our
schools and burn all the textbooks. Learning in a two way street--both teacher
and student have responsibilities. Enuf--this is costing me much more than it's
worth. And I'm afraid I'm starting to sound defensive and overly sensitive,
which I'm not! Ya just got me going--which you do so well.
There is 1 Reply.

#: 16319 S3/Languages
    27-Aug-92  16:32:58
Sb: #16300-#Your July article
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)
Bob,
Well, I suppose I could have been more mellow in my initial message, so I'll
apologize for that.  However, I think you miss my point.  I'm not saying that
void *malloc() is wrong per se, just that is is misleading to those people
trying to learn "C".  In your self-assumed role as a teacher of the subject, it
is your responsibility to be as clear as possible on the subject, even if it
means sticking to the more arcane OSK conventions than the newer ANSI stuff.  A
new "C" programmer might easily get confused when they see a function that
obviously returns something declared as a type void, no matter how "politically
correct" it may be.
Also, if you try to assign the return value of malloc() to an unsigned char
type, the compiler SHOULD complain because the two datat types are not the
same.  Declaring malloc() as a type void doesn't fix the problem, it meerly
masks it.  If you take a piece of code that has malloc return a char * type and
compare it to the same code but with malloc() returning a void * pointer, that
assembler for both of them is exactly the same.  That leads me to believe that
the compiler is not doing anything different, it just ignores any errors.
Of course, some more research should be done to confirm or deny this, but my
basic point is that same.  Again, I'll state that just because it appears in
headers for other compilers, does not make it a trueism for all compilers.
Mark
There is 1 Reply.

#: 16323 S3/Languages
    27-Aug-92  21:11:45
Sb: #16319-#Your July article
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)
Mark....
A few clarifications:
First, I don't have a 'self-assumed role as a teacher'. I'm just a guy writing
a few articles for which I get paid zip. So don't be too hard on me.
Second, it's interesting that 'The C Users Journal', Sept/92 issue (which I
just received) talks about this very point:
"So we defined pointer to void as a generic data-object poitner type. It has
the same representation as a character pointer, but much more lax conversion
rules. In fact, you can convert between a void pointer and any other
data-object pointer type without writeing a type cast. That gives the behavior
we wanted for function arguments and return values."
Third, I think that you might be getting a bit confused between void functions
and void pointers. They are quite different.
Fourth, there really shouldn't be any confusion for new C learners. They just
have to follow my instuctions and add the malloc.h header file. Since I'm using
void* there aren't any problems with compiling other programs, including stuff
ported from other systems.
Lastly, as to the tone of your initial comments and my replies.... well, that's
best just left alone.
There are 2 Replies.

#: 16327 S3/Languages
    28-Aug-92  14:42:19
Sb: #16323-Your July article
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)
Bob,
I realize you arn't doing these articles for the money.  What I mean when I say
"self-assumed role as a teacher" is, you, as the author of an article that is
showing (teaching) readers how to use termcap in their programs assume the role
as a teacher whether you want to or not and whether you get paid or not.  In
that context, you and you alone are responsible for the content of your
articles, right or wrong.  Many readers will see you and what you write as
gospel because they know no better and assume that you are giving them the
correct information.  That is the point I am trying to make.  You treat the use
of the void pointer in your article only with a rather glib reference that it
makes the compiler stop complaining and that is all.  It deserves more to
prevent reader confusion.  Take it from me, this will still happen no matter
how clear you try to make it, so at least try and clear it up for most of the
readers even if all of them won't understand.
Again, I say just because the ANSI committiee comes out with a void pointer for
their own innane reasons--and it happens to work on the OSK compiler, which was
designed long before then ANSI committiee was done haggling over the name of
their still-yet-to-be standard--doesn't mean you should assume it and the other
ANSIisums will work without some trouble down the road.  Now, if the OSK
compiler was billed as being fully ANSI compliant, that would be a different
matter.  By doing this, you may be setting up a reader to assume that it is
ANSI compliant.  Now this may not be your intent or your fault, but it would be
a result of using ANSI type statements with a non-ANSI compiler and inferring
that this is OK.  Again, your role as a teacher puts you in the position to
insure these sort of things do not happen as a result of what you say.
At the least, I think you should make a better explaination of it in your next
column, and in the future, make notes that any ANSI statements you use are
flagged as such and they may or may not work on the compiler the reader is
using.
Lastly, no, I know the difference between a void pointer and a void

#: 16328 S3/Languages
    28-Aug-92  14:53:24
Sb: #16323-#Your July article
Fm: Mark Griffith 76070,41
To: Bob van der Poel 76510,2203 (X)
(harrrrrump---truncated message)
Lastly, no, I know the difference between a void pointer and a void function. 
My point is the READER my not and assume the two are the same.  Again, your
responsibility to be clear.  You said before that is perfection is what is
called for, then we should fire all the teachers and learn it ourselves (or
something like that).  Well,  if you put yourself in the position as an
authority, you need to make your cases pretty well or someone will try to shoot
you down.  That is NOT what I am doing though.  If I had wanted to do that, I
would have written a letter the the editor, and got my thoughts published so
everyone would see how much smarter I was (I speak sarcastically there). (I
mean, I don't think I'm smarter, but that people how do those stupid things
think this is how they will be perceived).  I chose to mention it here, in this
rather obscure and little noticed forum, so as to not offend.  No one except
the regulars comes in here anyway anymore. Of course, if I had posted a reply
on Delphi, the discussion created would go on for years (bleah) 8^)
Lastly and lastly, voicing my opinion has nothing to do with my religion.  Does
being a religious person make posting a little "gruff" message any worse than a
teacher that posts misleading information?
MArk
There is 1 Reply.

#: 16337 S3/Languages
    29-Aug-92  21:39:11
Sb: #16328-Your July article
Fm: Bob van der Poel 76510,2203
To: Mark Griffith 76070,41 (X)
I was wondering what to write about after the termcap series was finished.
Guess I'll do something on declarations, header files, void pointers, etc...

#: 16315 S3/Languages
    27-Aug-92  02:54:32
Sb: #16297-Your July article
Fm: Mike Haaland 72300,1433
To: Mark Griffith 76070,41 (X)
Whoa Marky,
It's standard practice in Sys V.  So what's your real beef?  I understand you
don't agree.  It's OK, really.   Pesonally I have never even thought about it
since I always explicitly cast malloc() and the likes to the type it's being
used for.  But the OSK compiler handles it fine.  "Outside the scope of OSK" is
misleading and inaccurate in itself.  I too agree that it's more readable and
clearer to grasp what's going on if you cast malloc(), but it's seems to be a
matter of semantics, no?
Let's leave the verdict out.  You may see 'void *malloc()' in the ANSI release
of the Microware C compiler. ;-)
 - Mike -

#: 16648 S3/Languages
    10-Oct-92  23:09:09
Sb: #Jump tables in C
Fm: David Breeding 72330,2051
To: All
In "C", is there a call such that you can call a routine from a jump table? For
example, if you had an array    int *list[10], for example, then in the
program, is there a call where if you wished to execute the routine pointed to
by list[5], the program could do a "jsr ..."?
   Seems like I've seen this somewhere, but if so, I can't remember how it was
done.
   Oh, I'm referring to the CoCo version of "C".
Thanks, ....          David
There is 1 Reply.

#: 16649 S3/Languages
    11-Oct-92  11:39:38
Sb: #16648-Jump tables in C
Fm: Mike Haaland 72300,1433
To: David Breeding 72330,2051
I think Bob van der Poel wrote something about that.  Check with him. Bob's CIS
UID is 76510,2203.
 - Mike -
Press <CR> !>

#: 16712 S3/Languages
    17-Oct-92  21:53:27
Sb: #16649-Jump tables in C
Fm: David Breeding 72330,2051
To: Mike Haaland 72300,1433 (X)
Thanks, Mike.  Just read a message from him in mail.  He told me about the
articles.  I'll check them out.
  It was great getting to meet you in Atlanta.  Had a really good time.
Press <CR> !>

#: 16779 S3/Languages
    25-Oct-92  19:32:04
Sb: #A bedtime story
Fm: Carl Kreider 71076,76
To: Hackers
I have an interesting story for you C programmers.
While working on ar, I changed the table structure to use less memory (so that
more would fit in 64k) and promptly discovered that compression times had
doubled.  After a bit of sleuthing, I discovered that the simple change caused
three double shifts (mul by 8) to be replaced by a call to ccmult for a mul by
6.  Profiling the code shows that ar was spending 50% of it's time in ccmult.
The moral?   Make up your own ;-)  But at the least you should consider using
pointers instead of arrays.
Carl
There is 1 Reply.

#: 16785 S3/Languages
    26-Oct-92  09:29:33
Sb: #16779-#A bedtime story
Fm: Mark Griffith 76070,41
To: Carl Kreider 71076,76 (X)
Carl,
So what you are saying is that pointer arithmetic is faster than indexing into
an array?  I thought they worked the same?  In what way did you change the
structure size?
Inquiring minds want to know!  (grin)
Mark
There is 1 Reply.

#: 16828 S3/Languages
    31-Oct-92  22:01:04
Sb: #16785-A bedtime story
Fm: Carl Kreider 71076,76
To: Mark Griffith 76070,41 (X)
I changed the struct size from 4 shorts to 3 shorts, or from 8 bytes to 6
bytes.  The difference is that walking an array with pointers can be done by
addition.  ie ++p can be leau 6,u in the case above.  But using for (i = 0;
....) causes code like ldd i,s; pshs d; ldd #6; lbsr ccmult; addd p,s; tfr d,u;
then access the structure member. For random access to an array, using an index
is the only way, and array[i].elt is the same as *(array + i)->elt.  The saving
is when doing linear processing.
Oh, the problem with going from 8 bytes to 6 was that three shifts is mul by 8,
but the compiler calls multiply for 6 rather than doing ((i << 2) + (i << 1))
which is exactly the same as (i * 6).

#: 17076 S3/Languages
    16-Nov-92  18:45:57
Sb: C Development Tools
Fm: Stephen Seneker 75020,3611
To: ALL
Does anyone know of a any GOOD PD/Shareware C development tools.

#: 17210 S3/Languages
    04-Dec-92  10:39:28
Sb: #Structures in C-OS9 LII
Fm: Jon Beach 70004,1607
To: ALL
Greetings all.
I am a relatively new programmer in the C language and I have recently hit a
snag in a program that I am trying to write.  Ultimate purpose of the program
is to print out a nicely formatted monthly calender using a CoCo 3 and OS9
Level 2. 
I just tried to add code to the program that is supposed to extract the current
month and year from the system clock using the getime() function as defined in
the MicroWare and Carl Krieder C libraries for OS9 LII.
I am using the standard time.h file that defines the following structure:
struct sgtbuf {
        char   t_year,
                        t_month,
                        t_day,
                        t_hour,
                        t_minute,
                        t_second;
};
The section of code from my program is as follows:
#include <time.h>
.
.
.
main()
{
int month,year;
struct sgtbuf *timeinfo;
getime(timeinfo);
month = timeinfo.t_month;
year = timeinfo.t_year;
}
When compiled, this give "undeclared variable" and "struct member required"
errors for the timeinfo.t_month and timeinfo.t_year statements.
If I follow the example from the manual I have for the Krieder library and
declare timeinfo as follows:
        struct sgtbuf timeinfo;
I get the further error "cannot evaluate size".
Can any of you folks tell me what I am doing wrong and how to fix the problem. 
Like I say, I am relatively new to C and I have had no formal training in the
language.  Any assistance would be appreciated.  Thanks in advance.
There is 1 Reply.

#: 17213 S3/Languages
    04-Dec-92  20:14:27
Sb: #17210-Structures in C-OS9 LII
Fm: Bruce MacKenzie 71725,376
To: Jon Beach 70004,1607 (X)
Jon,
     Ok, first your declaration, 'struct sgtbuf *timeinfo;' , declares a
pointer to a structure (which is not what you really want--more on this la
later To access a structure element via a pointer you use the '->'
dereferencing opperator not the period.  Thus you should use 'month =
timeinfo->t_month' not 'month = timeinfo.t_month'.  This is the source of your
compiler errors, the compiler is looking for a structure named timeinfo whereas
you declared a structure pointer.
     Anyway, when a structure pointer is declared the compiler only sets aside
memory for a pointer, it does not set aside memory for the structure.
Furthermore, until it is initialized it will contain garbage.  If you call
gettime() with an unitialized pointer, gettime will store the structure data at
some random point in memory--a very dangerous proposition.
     So, you want to declare a structure as in the Kreider example.  This will
set aside variable memory large enough to receive the data from gettime(). But
gettime() expects a pointer to the structure as a parameter, not the structure
itself (which C won't let you do anyway--the source of your second compiler
error).  The way to generate a pointer to a variable is to use the '&'
referencing opperator.  Thus use 'gettime( &timeinfo );' to call the function.
     If this business of pointers is making your head spin, be reassured
pointers give most everybody fits at first.  They're neat once you catch on to
them though--they're the source of much of the power and flexibility of C.

#: 17255 S3/Languages
    14-Dec-92  18:09:09
Sb: #C question
Fm: Bill Dickhaus 70325,523
To: all
Is there any way to initialize a variable to the value of the offset of a field
within a structure? I want to initialize various structures with a table driven
approach, and don't want to have to initialize each offset or pointer variable
at run time.
        -Bill-
There is 1 Reply.

#: 17256 S3/Languages
    14-Dec-92  20:31:41
Sb: #17255-C question
Fm: Bob van der Poel 76510,2203
To: Bill Dickhaus 70325,523 (X)
Bill, hope we're not working on the same project <g>. I had to something which
I think is what you are asking. Code like:
 struct {
   char sc;
   int si;
   char *spc;
 }teststruct;
 char *test=&teststruct.spc;
Does produce the correct results with the 68K compiler. Don't know about the
6809... Oh, and remember that the above is NOT the best way to structure the
structure. 3 padding bytes are inserted inbetween 'sc' and 'si' for alignment.
You're best off to put the chars and shorts at the end of the structure. Mixing
chars and ints really eats up lots of memory when using structures.