Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbatt!ihnp4!ptsfa!ames!ucbcad!ucbvax!sdcsvax!sdcc6!sdcc18!ee163adj From: ee163adj@sdcc18.UUCP Newsgroups: comp.sys.ibm.pc Subject: MSC 4.0 bugs Message-ID: <699@sdcc18.ucsd.EDU> Date: Mon, 11-May-87 16:06:43 EDT Article-I.D.: sdcc18.699 Posted: Mon May 11 16:06:43 1987 Date-Received: Thu, 14-May-87 00:51:26 EDT Organization: University of California, San Diego Lines: 80 Keywords: Microsoft C 4.0 bugs The following are the responses I received about bugs in microsoft C 4.0. I have commented where I could add something to what was stated otherwise I Their response is how I received it. From: "Nelson H.F. Beebe" The one bug I have found is in sscanf() (and probably scanf() and fscanf(), though I haven't checked). Specifically, the format "%d:%d:%d" should return the number of fields successfully parsed for the function value. That is, it should return respectively 1, 2, and 3 for the inputs "3", "3:4", and "3:4:5". For the first two, it incorrectly returns 0. If the input is changed to "3:" or "3:4:", the returned value is correct. ------- I tried this one the problem shows up with sscanf in any model. -------------------------------------------------------------------------- From: seismo!vu-vlsi!colin@sdcsvax (Colin Kelley) The only bug I've run across is this: [it's been discussed at length in this newsgroup] The signal(SIGINT,...) routine does not function under MS-DOS 3.x, because it assumes that the stack segment and offset (SS:SP) have not been changed when an INT 23H (^C) is executed, when in fact MS-DOS has changed them in order to switch to an internal stack. This often results in a "stack overflow" or "stack underflow" error when the control-C handler is executed. The work-around is to install your own assembly language routine which first restores SS:SP and then jumps to the C ^C handler... -Colin Kelley ..{cbmvax,pyrnj,bpa}!vu-vlsi!colin --------------------------------------------------------------------------- From: ddl@husc6.HARVARD.EDU (Dan Lanciani) These are from memory, so you might want to try them... 1) overambitious constant elimination: foo(int_variable | 0L); passes a 16-bit quantity rather than a 32-bit one. Of course, 1L works just fine as does foo(int_constant | 0L); 2) This isn't explicitly a bug, but probably isn't what they wanted: (long)p != (long)(int)p for p char (near) pointer because conversion to a long causes the segment value to be inserted in the high word. This is strictly ok because conversion back to a pointer will truncate and that's all that is guaranteed anyway... 3) This really is a bug: (long)((char *)&thing - (char *)&other_thing) != (long)(int)((char *)&thing - (char *)&other_thing) Again, funny stuff happens to the high-order word. 2 and 3 are especially bad when the conversion to long happens implicitly as. Dan Lanciani ddl@harvard.* -------------------------------------------------------------------------- These are the only responses I got, if you know of any others please let me know. Steven "B.J." Martin