nather@ut-sally.UUCP (Ed Nather) (09/25/87)
I'm trying out Turbo C on a lot of C code that was written for (and
successfully compiled by) Microsoft C v4.0. The results so far are very
good: I've only had to add an explicit "fflush()" here and there that MSC
didn't really need, but probably should have had in there anyway.
The only real problem I've encountered is when I have named a function
of mine with the same name Turbo uses as a library function ... e.g. peek().
In MSC, library functions are selectively ignored if you have already defined
a function using the same name in your code, but Turbo gets all upset about
it, and refuses to acknowledge my inalienable right to pick overlapping names
for my functions. That's a simple way to replace a library funtion you
don't like.
I assume this is a known bug that will be fixed someday, but does anyone
have a workaround?
...Or am I just being dumb (again)?
--
Ed Nather
Astronomy Dept, U of Texas @ Austin
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather
nather@astro.AS.UTEXAS.EDUrichardh@killer.UUCP (09/27/87)
In article <9130@ut-sally.UUCP>, nather@ut-sally.UUCP (Ed Nather) writes: > The only real problem I've encountered is when I have named a function > of mine with the same name Turbo uses as a library function ... e.g. peek(). > In MSC, library functions are selectively ignored if you have already defined > a function using the same name in your code, but Turbo gets all upset about > it, and refuses to acknowledge my inalienable right to pick overlapping names > for my functions. That's a simple way to replace a library funtion you > don't like. > If you look in DOS.H, you'll discover that peek() is first declared as a function and then #defined as a macro. Could there be a conflict between the use of your own peek() function and this macro definition ? richard hargrove ...!ihnp4!killer!richardh -------------------------
maddox@ernie.Berkeley.EDU (Carl Greenberg (guest)) (10/04/87)
In article <1652@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: >If you look in DOS.H, you'll discover that peek() is first declared as a >function and then #defined as a macro. Could there be a conflict between >the use of your own peek() function and this macro definition ? In my Hercules graphics library that I've been fiddling with (I have set function in assembler, a fast line drawing algorithm, clear screen, that's it) I #undef peek and poke at the beginning before doing anything with them. And they don't seem to work on that segment except when you go into a memory model that supports far pointers... WAAAH. I suppose if I put EVERYTHING in assembler things will go OK, but not yet anyway... I hate going that low level... Carl /----------------------------------v------------------------------------------\ | Carl Greenberg, guest here | "I have a very firm grasp on reality! I | | ARPA: maddox@ernie.berkeley.edu | can reach out and strangle it any time I | | UUCP: ...ucbvax!ucbernie!maddox | want!" - Me |