ee163adj@sdcc18.UUCP (04/24/87)
I am going to try to make a list of errors in Microsoft C 4.0, so if you know of any please mail them to me. I will summarize to the net in a week or two. thanx in advance Steven "B.J." Martin ee163adj%sdcc18@sdcsvax.ucsd.edu sdcsvax!sdcc18!ee163adj
ee163adj@sdcc18.UUCP (05/11/87)
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" <Beebe@science.utah.edu>
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." Martinbonnieo@eagle_snax.UUCP (05/13/87)
I found the signal problem myself and didn't know why the stack was
getting screwed up - it can be gotten around, if I remember, with
a setjmp.
I also found some other 4.0 problems:
1) fgets will sometimes return 0D0A - only at end of file - the next
call to fgets will then return the null.
2) result = mktemp(template) corrupts the template after the call,
so that template must be reinitialized before mktemp
can be called again.
--
Bonnie Olszewski, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!bonnieo <OR> decvax!eagle_snax!bonnieotgl@mtgzz.UUCP (05/13/87)
/* statbugs.c */
#include "assert.h"
#include "stdio.h"
#include "sys/types.h"
#include "stat.h"
char *Device = "CON";
char *Executable = "\\COMMAND.COM";
char *Subdirdotdot = "\\BIN\\..";
struct stat Statb;
main()
{
int v;
v = stat(Device, &Statb);
assert(v == 0);
if ((Statb.st_mode & S_IFMT) != S_IFCHR)
printf("stat(%s,-).st_mode = %#x\t\tSHOULD BE 0x2---\n",
Device, Statb.st_mode);
v = stat(Executable, &Statb);
assert(v == 0);
if ((Statb.st_mode & S_IEXEC) == 0)
printf("stat(%s,-).st_mode = %#x\tSHOULD INCLUDE 0x--4-\n",
Executable, Statb.st_mode);
v = stat(Subdirdotdot, &Statb);
if (v != 0)
printf("stat(%s,-) = %d\t\t\tSHOULD BE 0\n", Subdirdotdot);
}
/**
C>statbugs
stat(CON,-).st_mode = 0x81b6 SHOULD BE 0x2---
stat(\COMMAND.COM,-).st_mode = 0x8124 SHOULD INCLUDE 0x--4-
stat(\BIN\..,-) = -1 SHOULD BE 0
**/dean@violet.berkeley.edu.UUCP (05/13/87)
A bug from MSC 3.0 that someone should check (I can't: I only have 3.0) concerns bugs introduced by setting the "-Wn" warning-level flag at compile time. If it is set to any level higher than the default, procedures returning floating point parameters sometimes return garbage. This behavior was noticed during "small" model compiles (other models not checked). I'd really like it if this bug has been squashed... -Dean (dean@violet.berkeley.edu)
cim2@pyuxv.UUCP (Robert L. Fair) (05/14/87)
Bonnie Olszewski, Sun Microsystems East Coast Division (home of PC-NFS) writes on the MSC 4.0 compiler: >2) result = mktemp(template) corrupts the template after the call, > so that template must be reinitialized before mktemp > can be called again. > UUCP: {ihnp4,decwrl,...}!sun!bonnieo <OR> decvax!eagle_snax!bonnieo THIS IS NOT A BUG ! This has been the *documented* functionality of mktemp(3) for many years - it replaces your template with the file name, and returns a pointer to the template. The alternative is for mktemp to malloc storage for the created name - not always desirable. Personally, I think mktemp s*cks - checkout tmpnam(3) and tempnam(3) as MUCH better and more flexible ways of creating temporary file names. (Also available on UNIX SYS-V) Bob Fair Bellcore/CHC ihnp4!pyuxww!pyuxv!cim2
bonnieo@eagle_snax.UUCP ( Sun ECD Software) (05/15/87)
I think it is a bug since it should be documented in the MSC manuals. I agree
with you that it s*cks - there should be a "see also" to tmpnam in both the
UNIX and MSC manuals.
--
Bonnie Olszewski, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!bonnieo <OR> decvax!eagle_snax!bonnieo