gilgalad@caen.engin.umich.edu (Ralph Seguin) (10/12/90)
Hi. Well, I picked up jrcomm, and VLT to try out. I found that JRComm doesn't work (probably my 030). VLT is pretty good. I cannot seem to find VTxxx emulation info in the menus. How does handshake stand up against these two? Is there a JRComm that doesn't hang on a 2500/30? Thanks, Ralph h gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET Ralph Seguin | "You mean THE Zaphod Beeblebrox?" 536 South Forest | Apartment 915 | "No. Haven't you heard, I come in six packs!" Ann Arbor, MI 48104 | (313) 662-4805
olson@uhunix1.uhcc.Hawaii.Edu (Toad) (10/12/90)
In article <1990Oct11.235942.2141@caen.engin.umich.edu> gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: >Hi. Well, I picked up jrcomm, and VLT to try out. I found that >JRComm doesn't work (probably my 030). VLT is pretty good. >I cannot seem to find VTxxx emulation info in the menus. >How does handshake stand up against these two? Is there a JRComm >that doesn't hang on a 2500/30? > JR-Comm 1.0 had a problem with certain 2091 controllers, the ones that hose location zero with a non-zero value, this has been fixed in 1.01. Other than that problem all of the JR-Comm versions have run fine on my 2500/30. JR-Comm 1.01 is adds a few new features (VT102 support) and fixes many bugs, there should be a demo version floating around on a local BBS, if not you can get one from the support BBS. -- olson@uhunix.uhcc.hawaii.edu | "When I was fourteen, my father was so ignorant olson@uhccux.uhcc.hawaii.edu | I could hardly stand to be around him. When I CS student, Adventurer | was twenty-one, I was amazed at how much the Paraphrased from House II | old man had learned in seven years." - M. Twain
joseph@valnet.UUCP (Joseph P. Hillenburg) (10/13/90)
gilgalad@caen.engin.umich.edu (Ralph Seguin) writes: > Hi. Well, I picked up jrcomm, and VLT to try out. I found that > JRComm doesn't work (probably my 030). VLT is pretty good. > I cannot seem to find VTxxx emulation info in the menus. > How does handshake stand up against these two? Is there a JRComm > that doesn't hang on a 2500/30? > > Thanks, Ralph > h > > gilgalad@dip.eecs.umich.edu gilgalad@zip.eecs.umich.edu > gilgalad@caen.engin.umich.edu Ralph_Seguin@ub.cc.umich.edu > gilgalad@sparky.eecs.umich.edu USER6TUN@UMICHUB.BITNET > > Ralph Seguin | "You mean THE Zaphod Beeblebrox?" > 536 South Forest | > Apartment 915 | "No. Haven't you heard, I come in six packs!" > Ann Arbor, MI 48104 | > (313) 662-4805 JR-Comm 1.01 works on an 020/030 under 2.0 on an A3000, which represent the extremes in Amiga compatability. -Joseph Hillenburg UUCP: ...iuvax!valnet!joseph ARPA: valnet!joseph@iuvax.cs.indiana.edu INET: joseph@valnet.UUCP
jesup@cbmvax.commodore.com (Randell Jesup) (10/23/90)
In article <9811@uhccux.uhcc.Hawaii.Edu> olson@uhunix1.uhcc.Hawaii.Edu (Toad) writes: >JR-Comm 1.0 had a problem with certain 2091 controllers, the ones that hose >location zero with a non-zero value, this has been fixed in 1.01. A note for all programmers out there: there is NO guarantee that location 0 will be 0. References to location 0 are bugs, and enforcer will trap and report them. Memmung stuffs a nasty value into location 0 to try to break incorrect programs. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (10/26/90)
In <458@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: >jesup@cbmvax.commodore.com (Randell Jesup) writes: > >> A note for all programmers out there: there is NO guarantee that >>location 0 will be 0. References to location 0 are bugs, and enforcer will >>trap and report them. Memmung stuffs a nasty value into location 0 to try >>to break incorrect programs. > >Would've been nice if this was common knowledge *before* the 2091 hit the >streets. Alot of programs got bit by this problem, and more than a few >were written by lawful coders too. Lawful coders initialize their pointers before use. Mistakes can be made, but that ends up creating a broken, as opposed to an illegal, program. It better be common knowledge. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jprad@faatcrl.UUCP (Jack Radigan) (10/26/90)
jesup@cbmvax.commodore.com (Randell Jesup) writes: > A note for all programmers out there: there is NO guarantee that >location 0 will be 0. References to location 0 are bugs, and enforcer will >trap and report them. Memmung stuffs a nasty value into location 0 to try >to break incorrect programs. Would've been nice if this was common knowledge *before* the 2091 hit the streets. Alot of programs got bit by this problem, and more than a few were written by lawful coders too. -jack-
peter@cbmvax.commodore.com (Peter Cherna) (10/26/90)
In article <458@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >jesup@cbmvax.commodore.com (Randell Jesup) writes: > >> A note for all programmers out there: there is NO guarantee that >>location 0 will be 0. References to location 0 are bugs, and enforcer will >>trap and report them. Memmung stuffs a nasty value into location 0 to try >>to break incorrect programs. > >Would've been nice if this was common knowledge *before* the 2091 hit the >streets. Alot of programs got bit by this problem, and more than a few >were written by lawful coders too. I hope you're saying that lawful coders can make mistakes. We strive to guarantee that if you program by the rules, then you will work. We do not guarantee the reverse: that if your program works, then we endorse the "rules" you used. There are many ways you can program incorrectly, often involving false assumptions. When possible and reasonable, we try to highlight those assumptions as wrong. Historically speaking, whenever a machine appears for which some assumption is no longer true, some software breaks. When problems arise, we have been known to jump hoops inside the system software because of some trick or mistake that used to work. Other times this is not practical, and we do work with developers to smooth out any problems. As well, we have developed a set of tools (Randell mentions some) that can establish that your code will survive in a more hostile environment than perhaps you and your testers might create. Continued compatibility is a shared and vital goal for us and developers alike. > -jack- Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer. "Television is a medium because it is neither rare nor well-done."
andy@cbmvax.commodore.com (Andy Finkel) (10/26/90)
In article <458@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >jesup@cbmvax.commodore.com (Randell Jesup) writes: > >> A note for all programmers out there: there is NO guarantee that >>location 0 will be 0. References to location 0 are bugs, and enforcer will >>trap and report them. Memmung stuffs a nasty value into location 0 to try >>to break incorrect programs. > >Would've been nice if this was common knowledge *before* the 2091 hit the >streets. Alot of programs got bit by this problem, and more than a few >were written by lawful coders too. > > -jack- If your program breaks when location 0 is non NULL this means you have an unitialized pointer somewhere in your program, and are using memory you did not allocate (ie location 0) I would have hoped that this would have been common knowledge amoung programmers long before the 2091 appeared. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "If your ancestors were alive today, what they'd probably be saying is: 'Where am I and why is it so dark ?' " Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
peter@sugar.hackercorp.com (Peter da Silva) (10/27/90)
I'd just like to add that any program, on any machine, that depends on some undocumented magic value being in location 0 (such as 0) is broken. Period. Blaming the 2091 for breaking broken code is futile. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (10/28/90)
In <465@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: >lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: > >>Lawful coders initialize their pointers before use. Mistakes can be made, but >>that ends up creating a broken, as opposed to an illegal, program. It better be >>common knowledge. > > True, mistakes can be made. But, most systems also have location zero >set to a null value and it *can't* be changed, unlike the Amiga, right? Doesn't matter.. broken code and illegal code is still the result of using uninitialized pointers. Just because a program works on one configuration/set of circumstances, it says nothing about the legality or robustness of said code. In other words, broken code is broken code, and if it gets shown up by something else that did something, rightly or wrongly, it is just as broken, the difference being that now you _know_ it's broken. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (10/28/90)
In <466@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes: >andy@cbmvax.commodore.com (Andy Finkel) writes: > >>If your program breaks when location 0 is non NULL this means >>you have an unitialized pointer somewhere in your program, and >>are using memory you did not allocate (ie location 0) > > Uh, according to K&R, NULL is a valid assignment for a pointer, so >how is it unitialized? > > Where I got bit is in a pathname building routine that I wrote which >did a strlen() without explicitly checking for NULL first, it now does. > > But, my question is the NULL pointer itself, if NULL is a valid constant, >then the location NULL should contain nothing either, right? > > If I somehow missed something so embarrassingly basic, how come I can't >find it in K&R, which is supposed to be the last word in 'C'? Don't know about K&R, but on the Amiga, you can specifically look at location 4, and expect a value there that is meaningful. There is no other absolute address that can be looked at, without using a label, allocating memory, allocating a resource, etc., and that can be expected to have a meaningful value. Same thing, essentially, with writing. Yes, NULL is a valid value for a pointer. If, however, you try to use it for anything other than an indication that the pointer is not initialized to something meaningful, you will get bitten. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jprad@faatcrl.UUCP (Jack Radigan) (10/29/90)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Lawful coders initialize their pointers before use. Mistakes can be made, but >that ends up creating a broken, as opposed to an illegal, program. It better be >common knowledge. True, mistakes can be made. But, most systems also have location zero set to a null value and it *can't* be changed, unlike the Amiga, right? -jack-
jprad@faatcrl.UUCP (Jack Radigan) (10/29/90)
andy@cbmvax.commodore.com (Andy Finkel) writes: >If your program breaks when location 0 is non NULL this means >you have an unitialized pointer somewhere in your program, and >are using memory you did not allocate (ie location 0) Uh, according to K&R, NULL is a valid assignment for a pointer, so how is it unitialized? Where I got bit is in a pathname building routine that I wrote which did a strlen() without explicitly checking for NULL first, it now does. But, my question is the NULL pointer itself, if NULL is a valid constant, then the location NULL should contain nothing either, right? If I somehow missed something so embarrassingly basic, how come I can't find it in K&R, which is supposed to be the last word in 'C'? -jack-
labb-2ae@e260-2d.berkeley.edu (Joe C.) (10/29/90)
In article <466@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >andy@cbmvax.commodore.com (Andy Finkel) writes: > >>If your program breaks when location 0 is non NULL this means >>you have an unitialized pointer somewhere in your program, and >>are using memory you did not allocate (ie location 0) > > Uh, according to K&R, NULL is a valid assignment for a pointer, so >how is it unitialized? The pointer is initialized to NULL. That means it is pointing to NOWHERE. You have to look at it from a data abstraction point of view. You're not supposed to *dereference* a NULL pointer, because again, it is pointing to NOWHERE. > But, my question is the NULL pointer itself, if NULL is a valid constant, >then the location NULL should contain nothing either, right? Again, your supposed to look at the data abstraction point of view. To say what "location NULL" contains is meaningless. Your pointer is NULL; don't say it is pointing to NULL, rather it *is* NULL. Anyway, you're not supposed to dereference a NULL, so it doesn't matter that NULL is 0, and location 0 might contain anything. Dereferencing a NULL is like asking: where is nothing pointing to? -jc --- labb-2ae@web.berkeley.edu
peter@sugar.hackercorp.com (Peter da Silva) (10/29/90)
In article <465@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: > True, mistakes can be made. But, most systems also have location zero > set to a null value and it *can't* be changed, unlike the Amiga, right? No, most systems worth mentioning have location 0 *illegal*. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/29/90)
jprad@faatcrl.UUCP (Jack Radigan) writes: >jesup@cbmvax.commodore.com (Randell Jesup) writes: > >> A note for all programmers out there: there is NO guarantee that >>location 0 will be 0. References to location 0 are bugs, and enforcer will >>trap and report them. Memmung stuffs a nasty value into location 0 to try >>to break incorrect programs. > >Would've been nice if this was common knowledge *before* the 2091 hit the >streets. Alot of programs got bit by this problem, and more than a few >were written by lawful coders too. > > -jack- It's been common knowledge as long as there has been a C language that dereferencing a null pointer in C is a bug. I don't think Commodore was under any special obligation to jump up on that soapbox again; that harangue has been done to death. Buggy code is buggy code, and trying to blame it on the hardware vendor when it bites you is a bit lame. /// It's Amiga /// for me: why Kent, the man from xanth. \\\/// settle for <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> \XX/ anything less? -- Convener, ongoing comp.sys.amiga grand reorganization.
new@ee.udel.edu (Darren New) (10/29/90)
In article <466@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >andy@cbmvax.commodore.com (Andy Finkel) writes: > But, my question is the NULL pointer itself, if NULL is a valid constant, >then the location NULL should contain nothing either, right? Zero is a valid value for an integer, but you can't divide by it. NULL is a valid value for a pointer, but you can't indirect by it. Since most people don't intend to indirect by NULL, and most static pointers begin life as NULL, most people assume that if you get bit by the NULL pointer mistake that it was because you had an uninitialized pointer. I actually find (in my experience) it is more often failure to check for errors from malloc() than uninititalized pointers. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, Formal Description Techniques (esp. Estelle), Coffee -----
papa@uscacsc.usc.edu (Marco Papa) (10/29/90)
In article <465@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>Lawful coders initialize their pointers before use. Mistakes can be made, but >>that ends up creating a broken, as opposed to an illegal, program. It better be >>common knowledge. > > True, mistakes can be made. But, most systems also have location zero ^^^^^^^^^^^^ >set to a null value and it *can't* be changed, unlike the Amiga, right? ^^^^^^^ Where did you get those ideas? I guess you've never seen what happens when you start clearing low-mem on one of the >15M pcs out there, or macs for that matter. On UNIX location zero can't be changed, but if accessed your program will get i big nice segmentation violation. I wonder what systems you're talking about. Your is a *big* cop out. Thre are *no* excuses for buggy software. BTW, there has NEVER been a Commodore document that says that location zero is set to null. Assuming anything like that for the Amiga is simply stupid. -- Marco
papa@uscacsc.usc.edu (Marco Papa) (10/29/90)
In article <466@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >andy@cbmvax.commodore.com (Andy Finkel) writes: >>If your program breaks when location 0 is non NULL this means >>you have an unitialized pointer somewhere in your program, and >>are using memory you did not allocate (ie location 0) > > Uh, according to K&R, NULL is a valid assignment for a pointer, so >how is it unitialized? Initializing a pointer to NULL is just fine. > Where I got bit is in a pathname building routine that I wrote which >did a strlen() without explicitly checking for NULL first, it now does. Bad boy :-) > But, my question is the NULL pointer itself, if NULL is a valid constant, >then the location NULL should contain nothing either, right? WRONG! The following is verbatim from K&R, p. 97, first edition: "C guarantees that no pointer that validly points at data will contain zero, so a return value of zero can be used to signal an abnormal event ...". This means that "dereferencing" a pointer to NULL is INVALID, since such pointer "does not validly points to data". > If I somehow missed something so embarrassingly basic, how come I can't >find it in K&R, which is supposed to be the last word in 'C'? Yes, that's pretty basic. You didn't read well enough, I guess :-) -- Marco
mab@drutx.ATT.COM (Alan Bland) (10/29/90)
In article <466@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: > But, my question is the NULL pointer itself, if NULL is a valid constant, >then the location NULL should contain nothing either, right? > > If I somehow missed something so embarrassingly basic, how come I can't >find it in K&R, which is supposed to be the last word in 'C'? I don't have K&R handy, and I can't find any mention of the subject in my other available references, but plain old experience tells me that it is incorrect to dereference a NULL pointer. Regardless of whether you rely on what happens to be stored at location zero, simply trying to read what's there will cause problems on some machine architectures (some UNIX boxes will "core dump" a process that merely glances in the general direction of location zero). It's most definitely non-portable. I'm sure I'm not the only one, but attempting to dereference a NULL pointer is one of those basic no-no's that I thought was obvious to everyone. Kind of like trying to read past the end of an array; C lets you do it, and sometimes it works, but you better not rely on it to always behave the same way. -- -- Alan Bland -- att!drutx!mab == mab@drutx.ATT.COM -- AT&T Bell Laboratories, Denver CO -- (303)538-3510
mcmahan@netcom.UUCP (Dave Mc Mahan) (10/30/90)
In a previous article, jprad@faatcrl.UUCP (Jack Radigan) writes: >andy@cbmvax.commodore.com (Andy Finkel) writes: > >>If your program breaks when location 0 is non NULL this means >>you have an unitialized pointer somewhere in your program, and >>are using memory you did not allocate (ie location 0) > > Uh, according to K&R, NULL is a valid assignment for a pointer, so >how is it unitialized? > > But, my question is the NULL pointer itself, if NULL is a valid constant, >then the location NULL should contain nothing either, right? I don't think so. Just because NULL is a valid initialization for a pointer doesn't mean that it HAS to point to something legal. After all, what is your definition of legal? K&R just states that all static and global variables will default to NULL, I don't think it says anything about what the NULL location has to contain. It is also legal to set an integer pointer to an odd address on the 68000 CPU. Just don't try to use it though. :-) > -jack- -dave
dailey@frith.uucp (Chris Dailey) (10/31/90)
In article <15412@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >In article <458@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >>jesup@cbmvax.commodore.com (Randell Jesup) writes: >>> A note for all programmers out there: there is NO guarantee that >>>location 0 will be 0. References to location 0 are bugs, and enforcer will >>>trap and report them. Memmung stuffs a nasty value into location 0 to try >>>to break incorrect programs. >>Would've been nice if this was common knowledge *before* the 2091 hit the >>streets. Alot of programs got bit by this problem, and more than a few >>were written by lawful coders too. >I hope you're saying that lawful coders can make mistakes. We strive Just because something is lawful also doesn't mean that it is the correct or most elegant way of doing things. Depending on location 0 to hold a specific value isn't a very portable way of coding. Even if code is not intended to be ported, I think the programmer should try to keep in mind techniques that lead to easy porting. You never know. I guess still being a student I have extreme ideals (which are at times impractical), such as if it's worth writing, it's worth writing well. >Continued compatibility is a shared and vital goal for us and developers >alike. >> -jack- > Peter -- Chris Dailey dailey@(frith.egr|cpsin.cps).msu.edu "Rise again, rise again/Though your heart it be broken and life about to end./No matter what you've lost, be it a home, a love, a friend,/ Like the Mary Ellen Carter, rise again!" -- a song by the late Stan Rogers