darrylo@hpsrlc.UUCP (06/16/87)
In comp.sys.ibm.pc, morearty@cory.Berkeley.EDU (Mike Morearty) writes: > I have encountered two bugs in Turbo C that are worth mentioning: > > (1) strstr() has problems. One problem was mentioned in a previous Turbo C has a number of bugs, most of which get fixed soon after they are found. Borland seems to be fixing bugs and shipping the fixed versions of the compilers to new customers (they don't seem to change the revision number, though). For example, one early version of the (shipped) compiler had problems with dividing floating-point constants (4.0 / 2.0 would give 0.5 or somesuch). By the time I bought my copy, the compiler didn't have the bug (it was still called version 1.0, however -- fortunately, the timestamp does change). I get the impression that the longer one waits, the less bugs the compiler will have (not that Turbo C is buggy). There are other bugs in Turbo C, but Borland has issued patches for most of them. By patches, I mean actual instructions like "take out debug and change the value at AAAA:XXXX from YY to ZZ". Among the bugs fixed are: 1. "Out of memory" error using the command-line version of the compiler with the "-G" option (optimize for speed). 2. Problems with passing a structure containing floats to a function. 3. The strstr() bug mentioned. This was fixed by someone (not Borland?) simply rewriting the routine. 4. Problems with dividing floating-point constants. Even with the bugs it has (the ones above don't bother me as patches have been issued), I like Turbo C (the compile speed is WONDERFUL). Having warnings like "possibly incorrect assignment" in an "if" statement (should be equality, not assignment) is really nice! [...] > > -- > Mike Morearty > ARPA: morearty@cory.Berkeley.EDU USENET: ucbvax!cory!morearty > ---------- -- Darryl Okahata hplabs!hpcea!hpsrla!darrylo CompuServe: 75206,3074 Disclaimer: the above is the author's personal opinion and is not the opinion or policy of his employer or of the little green men that have been following him all day.
bright@dataio.Data-IO.COM (Walter Bright) (06/18/87)
In article <3320022@hpsrlc.HP.COM> darrylo@hpsrlc.HP.COM (Darryl Okahata) writes: >Even with the bugs it has (the ones above don't bother me as patches have >been issued), I like Turbo C (the compile speed is WONDERFUL). Having >warnings like "possibly incorrect assignment" in an "if" statement (should >be equality, not assignment) is really nice! Datalight C has been issuing this warning for the last year and a half. It will also issue the same warning on things like: while (a = b) ... and on d = a && b = c; ... Basically, the warning is given whenever an assignment is implicitly tested for 0 or !=0. To get rid of the warning, compile with -w or: while ((a = b) != 0) ... and d = a && (b = c) != 0; This will also flag to the person maintaining your code that you really did mean the assignment. Disclaimer: I have no connection with Datalight other than the fact that I wrote the compiler and receive money from sales of it.
lyourk@ihlpf.ATT.COM (Loran N. Yourk) (06/19/87)
in article <3320022@hpsrlc.HP.COM>, darrylo@hpsrlc.HP.COM (Darryl Okahata) says:
] There are other bugs in Turbo C, but Borland has issued patches for
] most of them. By patches, I mean actual instructions like "take out debug
] and change the value at AAAA:XXXX from YY to ZZ". Among the bugs fixed are:
]
: : :
: : :
]
]
] -- Darryl Okahata
] hplabs!hpcea!hpsrla!darrylo
] CompuServe: 75206,3074
]
] Disclaimer: the above is the author's personal opinion and is not the
] opinion or policy of his employer or of the little green men that
] have been following him all day.
Could someone please post the patches. I would assume more than few
other readers would be interested in them. If they were posted
before I never seen them (except for the routine which was
re-written).
Loran Yourk
ihnp4!ihlpf!lyourkwrp@krebs.UUCP (06/19/87)
Last night I discovered another problem which I have not yet been able to track down. Apparently, incorrect code is generated in some cases when an array of structures is being accessed. I have code in which x = sarr[i].v - arr[j-sarr[i+1].p]; goes into never never land but tmp = j - sarr[i+1].p; x = sarr[i].v - arr[tmp]; works. Unfortunately, it may not work correctly, because the program that uses this code returns the wrong answer. This code works fine under Lattice, Microsoft, VAX/VMS, Xenix, and SysVR2 compilers. Bill Pearson ...!seismo!virginia!wrp wrp@virginia.BITNET
bobmon@iuvax.UUCP (06/20/87)
> There are other bugs in Turbo C, but Borland has issued patches for >most of them. By patches, I mean actual instructions like "take out debug Well, I sent in the "free Compuserve time" card that came with the compiler, but I expect to spend much of that "free time" figuring out how to get into the Borland SIG. Is there any other way to find out about these patches? I'm really not that eager to spend lots of my time and money getting bugfixes out of a customer service organization, even if they're not the ones profiting from the connection.
jpn@teddy.UUCP (John P. Nelson) (06/23/87)
>> I have encountered two bugs in Turbo C that are worth mentioning: >> >> (1) strstr() has problems. And here is a replacement, source code. char *strstr (keystr, targetstr) char *keystr, *targetstr; /* Features of Operation: - If keystr or targetstr is NULL, a NULL pointer (failure) is returned (i.e., NULL pointer input is handled gracefully). - If keystr or targetstr contains only a NULL character, a NULL pointer (failure) is returned (i.e., NULL's are not considered characters for the purpose of this function -- they are considered string terminators). - The search terminates successfully when '\0' of keystr is encountered before (or at the same time) as '\0' of targetstr. The search terminates unsuccessfully when '\0' of targetstr is reached before '\0' of keystr. */ { register unsigned short i; if (keystr == (char *) 0 || targetstr == (char *) 0) return ((char *) 0); if (*keystr == '\0' || *targetstr == '\0') return ((char *) 0); do { for (i = 0; *(keystr+i) && (*(keystr+i) == *(targetstr+i)); i++); if ( !(*(keystr+i)) ) return (targetstr); } while (*(targetstr++)); return ((char *) 0); } As you can see, this replacement handles NULL pointer input gracefully, is completely iterative and uses no calls to other library routines (for speed). It's also 4 bytes _shorter_ than the original Borland version. And, as far as I've been able to determine, it works! Brad Paulsen: Compuserve 76703,1005