root@qetzal.UUCP (Admin) (07/22/87)
Here is the list of bugs which have been submitted thus
far. They are not in a format suitable for Microport yet,
and must be placed on the forms. Please feel free to
elaborate. Send any bugs to isis!qetzal!uportlist or
ihnp4!upba!qetzal!uportlist. Bugs already documented by
Microport, unless extremely obnoxious, are omitted from
this list.
1. dd(1) and mail(1) need to be recompiled with a unsigned long
data length so that they don't say wrong things. (5 minute fixes).
2. csh(1) needs to have variables exported properly. This would
fix several broken programs that require these variables like newgrp(1).
3. malloc(3) and malloc(3X) produce different results sometimes ending
in a core dump (segmentation violation). Working code usig malloc(3)
will fail to run when compiled identically with malloc(3X). This is a
'286 architechure problem with sbrk(2) that Microport knows about and
hates.
4. TSS and double fault panics for seemingly no good reason. No OS
should "just crash". Problem still occurrs in 2.2.2.
5. fdisk(1) has some undocumented features like destroying bad sector
information when changing partitions. Why does Microport need to use a
different means of bad sector forwarding that does the rest of the DOS/
Xenix world? Fdisk(1) should never destroy bad sector information even
when the active partion or any other partition boundry is changed.
6. Shell layering is necessary for people on terminals to do efficient
development. It was promised in advertising in 8/86 and is still in the
to-be-in-the-next-release category.
7. Release of source code for attaching shared memory as the code so far
in packaged form is extremely lacking. (Both shmcreate and shmvidkey
were buggy and not efficient calls from within C.)
8. Console keys can give too many characters to vi(1). This is a SVr2
bug in vi(1) that uses the alarm call. It could be fixed. Also, vi(1)
has a bug in which it will enter ex(1) mode after fast keystrokes (like "yy")
even on terminals.
9. Problems with SIO crashes. This is problem #1 for us right now.
The system will drop characters at any baud rate over 300, and it doesn't
take a lot of coaxing to make it occur (just some load on the serial
ports). Also, the system panics in the driver, routine 'rmsd').
Compiler problems -- specifically:
10. Passing (char *) NULL to a function in a large model program can cause
a core dump/program abort. This makes some programs, which work under
small model, fail under large for no apparent reason. Symptom is that
the dump occurs between the function call and the first executable
instruction in the function itself (usually a Mem fault or Segv)
This blows up a LOT of things, including printf("%s", (char *) NULL)
(or equivalent). Since you quite often are in this situation when you
are reading/writing files in the standard I/O system, you have to code
around the possibility (ie: test first before allowing it to be
called). Not nice! One problem with this in particular is that it is
not consistant -- at least not in terms of what must precede it to
cause a fault. Sometimes it works, sometimes not (more often not).
11. You cannot use an array of pointers to point to >64K of data. This is
a very significant irritant.
12. Varargs problems (dumps core on statements using this capability).
This may be the same problem as (a), in that the unused arguments are
not declared and could default to anything.
13. Potential memory allocation problems -- occasionally a well-behaved
program, ESPECIALLY if using Microports' 'improved' malloc library,
will core dump for no apparent reason. Investigation with 'sdb' shows
that a malloc dumped it, or sometimes a function call will pass junk
instead of the values (instant dump if there's a pointer being passed!)
14. Uucp problems -- these have been acknowledged (jmsully@microp), and they
have told me that HoneyDanber will be an installable option on release
2.3. This might fix the uucp problem entirely. What I get now is an
inordinate number of failed calls, lost packets, etc. Probably at
least mildly related to problem (9). Also, core dumps in -x1-9 modes
(probably related to one or more of the compiler problems).
15. Providing what you say you will. Specically, we received the dialer
upgrade some months ago. The documentation specifically mentions two
programs that are not included in the 'upgrade', and this was a PD
package! We've also had things 'left out' or 'not included' when we order
upgrades, stuff that ANYONE doing development would need -- like a link
kit. Then, of course, they want to charge you (again) to complete your
order...Along this line is the revelation of problems like the serial
panics when asked -- their sales staff has been less than truthful about
this stuff with us in the past. If it simply is a case of 'I don't know',
then they need more education and/or a current bug list on their desks.
16. 2.2.2's wall is broken. No idea how that happened, but 'wall' now gives a
complaint and exits (Bus error - core dumped).
17. Along the same line, so is 'ps' with no arguments (produces nothing,
should show your processes.) 'ps' with arguments works fine. New problem
with 2.2.2.
18. Sdb will sometimes complain "can't allocate memory for symbol table; Goodbye"
Seems as though this is related to the garbaged memory allocation and/or
the (char *) NULL problem, as those traps always seem to produce these
failures of sdb to read the file. (Note: we have 4.5M of memory here,
there is NO reason why SDB cannot get enough core to debug a 250K
executable file!) Happens on large model programs only.
19. File systems larger than 300,000 blocks get trashed repeatedly.
[Need more info - ed.]
20. The version of easyinstall for 2.2.2 is broken. The shell script
crashes after the second question.
21. The documentation is extremely inadequate when attempting to
install a secondary hard disk. I've destroyed the partition
table on my PRIMARY hard disk numerous times.
22. The requirements for adding additional memory cards to the
system needs to be stated. NMI errors occur if the wrong types
of cards are used.
23. Many if not all shell scripts distributed do not include a ':'
character at the beginning. This means that the user must edit
each shell script when it is distributed so that it will run
under csh.
----------------------------------------------------------------------root@hobbes.UUCP (John Plocher) (07/23/87)
+---- (Robert White) writes the following in article <166@qetzal.UUCP> ---- | | Compiler problems -- specifically: | | 10. Passing (char *) NULL to a function in a large model program can cause | a core dump/program abort. This makes some programs, which work under | small model, fail under large for no apparent reason. Symptom is that | the dump occurs between the function call and the first executable | instruction in the function itself (usually a Mem fault or Segv) | This blows up a LOT of things, including printf("%s", (char *) NULL) | (or equivalent). +---- WRONG! Passing the NULL pointer is not what is wrong! What IS wrong is the ASSUMPTION that the data stored at location NULL is anything useful! printf("%s", (char *) NULL); says print the string at address 0. This happens to work on a VAX because that machine SPECIFICALLY has set things up so that the contents of location 0 is 0. This bad coding practice hits owners of Sun machines as well and is NOT a compiler bug. +---- | 17. Along the same line, so is 'ps' with no arguments (produces nothing, | should show your processes.) 'ps' with arguments works fine. New problem | with 2.2.2. +---- Try removing the file /etc/ps_data This will make ps work again. ps_data is a cache of namelist info from /unix; when you changed versions, you forgot to invalidate the 'cache'. FLAME: ps should check the dates on /unix and on /etc/ps_data and do the invalidation itself! -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU
karl@ddsw1.UUCP (Karl Denninger) (07/25/87)
In article <157@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes: > +---- (Robert White) writes the following in article <166@qetzal.UUCP> ---- > | > | Compiler problems -- specifically: > | > | 10. Passing (char *) NULL to a function in a large model program can cause > | a core dump/program abort. This makes some programs, which work under > | small model, fail under large for no apparent reason. > WRONG! Passing the NULL pointer is not what is wrong! What IS wrong > is the ASSUMPTION that the data stored at location NULL is anything useful! > +---- > | 17. Along the same line, so is 'ps' with no arguments (produces nothing, > | should show your processes.) 'ps' with arguments works fine. New problem > | with 2.2.2. > +---- Hmmm... Some things to consider: a) NULL is declared in large model programs to be '0L' (look in the header file) b) (char *) variable, where variable contains 0, works in this situation. (char *) NULL does not. c) I am *not* passing NULL, but rather a POINTER to it. The value pointed TO at that location should BE the null! Will be more than happy to eat my bug report if there's a good reason why the cast which I included does not produce the desired result -- especially if someone can explain why example (b) works! I *have* removed the file /etc/ps_data -- makes no difference. Here we get only the banner (PID, etc), and NO data -- unless you specify a switch like 'ps -ef', then it works fine! -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)
root@hobbes.UUCP (John Plocher) (07/26/87)
Followup to the NULL pointer stuff in the comp.lang.c group, please. +---- Karl Denninger writes the following in article <245@ddsw1.UUCP> ---- | John Plocher writes: | > +---- (Robert White) writes | > | 10. Passing (char *) NULL to a function in a large model program can cause | > | a core dump/program abort. | > WRONG! Passing the NULL pointer is not what is wrong! What IS wrong | > is the ASSUMPTION that the data stored at location NULL is anything useful | | Hmmm... Some things to consider: | a) NULL is declared in large model programs to be '0L' (look in the | header file) This is 100% WRONG! Microport SCREWED IT UP! NULL should be 0, not 0L! The reason it is incorrectly set to 0L is that programmers rarely bother to cast NULL when passing it as a parameter to functions: foobar(NULL); is wrong. It should be done like this: foobar( (char *)NULL ); (See discussion in comp.lang.c from March 87) | b) (char *) variable, where variable contains 0, works in this | situation. (char *) NULL does not. WRONG. Neither work. An example: /* cc -Ml foo.c ; a.out */ #include <stdio.h> main() { int p; p = 0; /* "(char *) variable, where variable contains 0" */ printf("int: %s\n",(char *)p); printf("NULL: %s\n",(char *) NULL); } This routine "segmentation faults" in the 1st printf(). Why? On page 97 of K&R it states: "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, in this case, no space. We write NULL instead of zero, however to indicate more clearly that this is a special value for a pointer." | c) I am *not* passing NULL, but rather a POINTER to it. The value | pointed TO at that location should BE the null! What you said: char *p = "\0"; /* A pointer to an array with NULL */ /* the value of the first element */ -or- int x; /* a place for a value */ int *p; /* a pointer */ p = &x; /* points to the variable x which */ *p = 0; /* now contains a value of zero */ What you did: char *p; /* A pointer ... */ p = 0; /* ...whose value is NULL */ Do you see the difference? In graphical terms: variable contents of contents of name variable memory address1 -------- ----------- --------------- What you said: p: [ address1 ] ----------> [ 0 ] What you did: p: [ 0 ] In the first case you have a pointer TO the memory location which contains the value zero. In the second case you have a pointer WHOSE VALUE IS zero. By virtue of K&R (quoted above) a pointer whose value ia zero CAN NOT POINT TO ANYTHING, much less the value 0! If it does HAPPEN TO WORK, "this kind of code in inherently risky, for it depends on details of implementation and machine architecture which may not hold for the particular compiler you use." Unfortunately, the VAX pcc compiler, the 80386 pcc compiler, and a few others have decided that a pointer whose value is zero also points to a zero value: p:[ 0 ] -------> [ 0 ] This did make life easier for lazy programmers: (What happens if this is passed a NULL pointer?) while (*s++) { ... } /* Works on a VAX, but not on a Sun */ instead of the correct (and robust and portable): while ( s && *s++) { ... } | Will be more than happy to eat my bug report if there's a good reason why | the cast which I included does not produce the desired result -- especially | if someone can explain why example (b) works! Example (b) does not work. (-: Munch Munch? :-) | > +---- | > | 17. Along the same line, so is 'ps' with no arguments (produces nothing, | > | should show your processes.) 'ps' with arguments works fine. New problem | > | with 2.2.2. | > +---- | I *have* removed the file /etc/ps_data -- makes no difference. Here we get | only the banner (PID, etc), and NO data -- unless you specify a switch like | 'ps -ef', then it works fine! MAKE SURE that /unix is linked with /system5! Other than that, I don't know what could be the problem. My stuff works. Also note that /bin/ps has not changed! >> uname -a system5 hobbes 2 2.2.2-L AT >> ls -la /unix /bin/ps -rwxr-sr-x 1 root sys 29202 Oct 26 1985 /bin/ps -rw-rw-r-- 3 bin bin 290011 Jun 19 00:26 /unix >> ps PID TTY TIME COMMAND 105 cons3 0:05 csh 9316 cons3 0:12 csh 21023 cons3 0:00 ps >> | Karl Denninger UUCP : ...ihnp4!ddsw1!karl | Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) - John ^G: +1 (608) 655-3691 Karl, call me if you want... -- John Plocher uwvax!geowhiz!uwspan!plocher plocher%uwspan.UUCP@uwvax.CS.WISC.EDU
john@xanth.UUCP (John Owens) (07/27/87)
In article <245@ddsw1.UUCP>, karl@ddsw1.UUCP (Karl Denninger) writes: > a) NULL is declared in large model programs to be '0L' (look in the > header file) This is incorrect, and a kludge to "help" those programs that pass NULL to functions without casting it first. NULL should be "0" for all models, and should always be cast to the appropriate type to get its length right. (I.E., passing "(char *) 0" in small model will push 16 bits of zeros; passing the same thing in large model will push 32 bits.) > b) (char *) variable, where variable contains 0, works in this > situation. Sure, since you are passing an address which points to something; in this case, it points to a zero character. See below: > . . . (char *) NULL does not. > c) I am *not* passing NULL, but rather a POINTER to it. The value > pointed TO at that location should BE the null! No, you *are* passing NULL, which is 0. There *is* no value that this points to - that's why it's NULL. Why do you think you're passing a pointer to NULL? The cast? No, that just changes the type. It is always illegal to dereference NULL. The confusion comes about because many implementations, again to "help" incorrect programs, make sure to put a zero word (or more) at location zero, so that incorrectly dereferencing NULL will still get you a null string, or whatever (depending on type). In small model, Xenix does this, so you can dereference DS:0000 with no error. In large model, it can't let you dereference 0000:0000, so you get a segmentation fault. > Will be more than happy to eat my bug report if there's a good reason why > the cast which I included does not produce the desired result -- especially > if someone can explain why example (b) works! I hope I've explained it clearly - if not, let me know. Again, the cast, in this case, just makes sure the argument passed on the stack is the right size. -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {decuac,harvard,hoptoad,mcnc}!xanth!john
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (07/27/87)
In article <245@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes: >In article <157@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes: >> ... deleted stuff about printing NULL with %s in printf ... >Hmmm... Some things to consider: >a) NULL is declared in large model programs to be '0L' (look in the > header file) This is kind of a kluge. The ANSI standard proposes making this "(void *) 0" which works in all models. >b) (char *) variable, where variable contains 0, works in this > situation. (char *) NULL does not. Peculiar to your machine. Neither work on machines here. >c) I am *not* passing NULL, but rather a POINTER to it. The value > pointed TO at that location should BE the null! Regardless of what you think you are doing, you are passing the value 0L cast to a pointer to char. To pass a pointer to NULL you need to say "&NULL" which blatently won't work because NULL is a constant, not a variable. > >Will be more than happy to eat my bug report if there's a good reason why >the cast which I included does not produce the desired result -- especially >if someone can explain why example (b) works! Hope you're not counting calories, and I'm sure others will also help correct your perception of how casts work. > >Karl Denninger UUCP : ...ihnp4!ddsw1!karl >Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) >"Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs) It seems that the problem here is that the printf version being used does not recognize NULL and protect itself. When it tries to go indirect through the NULL pointer it gets an address which is not valid, and thereby a segmentation violation. -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
theo@natmlab.dms.oz (Theo ten Brummelaar) (07/28/87)
In article <245@ddsw1.UUCP>, karl@ddsw1.UUCP (Karl Denninger) writes: > Hmmm... Some things to consider: > a) NULL is declared in large model programs to be '0L' (look in the > header file) > b) (char *) variable, where variable contains 0, works in this > situation. (char *) NULL does not. > c) I am *not* passing NULL, but rather a POINTER to it. The value > pointed TO at that location should BE the null! > Will be more than happy to eat my bug report if there's a good reason why ... In my understanding (char *) NULL is casting NULL as a pointer to a char *NOT* a pointer to the value of NULL. A pointer whose value is NULL is not usually meaningfull (is it ? ). If , as I think you mean , you want to pass a POINTER to a character whose value is NULL you should use (char *) &(NULL). I can not comment on why (char *) variable works but I question the whole reason for wanting to pass a null pointer except as an error condition for a function like malloc(). The reason , I think, that (char *) NULL does not work is that it has no real meaning other than 'something is wrong'. Feel free to explain why I am wrong, if I am. Theo ten Brummelaar ---------------------------------------------------------------------------- C.S.I.R.O. Division of Applied Physics , Linfield , Sydney , Australia. ---------------------------------------------------------------------------- Time flies like an arrow , fruit flies like an orange. ---------------------------------------------------------------------------- ACSnet: theo@natmlab CSNET: theo@natmlab.oz ARPA: theo%natmlab.oz@seismo.css.gov JANET: natmlab.oz!theo@ukc UUCP:{enea,hplabs,mcvax,prlb2,seismo,ubc-vision,ukc}!munnari!natmlab.oz!theo ----------------------------------------------------------------------------
karl@ddsw1.UUCP (Karl Denninger) (07/28/87)
In article <158@hobbes.UUCP>, root@hobbes.UUCP (John Plocher) writes: > > Example (b) does not work. (-: Munch Munch? :-) (Summary sez it best) -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8909 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)