Path: utzoo!attcan!uunet!tektronix!percival!littlei!omepd!jhunt From: jhunt@omews3.intel.com (Jim Hunt) Newsgroups: comp.sys.ibm.pc Subject: Turbo C 1.5 malloc bug? Message-ID: <3960@omepd> Date: 28 Nov 88 20:44:09 GMT Sender: news@omepd Reply-To: jhunt@omews3.intel.com (Jim Hunt) Distribution: na Organization: Intel Corp., Hillsboro Lines: 49 I have been programming with Turbo C 1.5 recently and have found what appears to be a bug in the code generated for a malloc call. USUALLY the code that is generated looks something like this: mov ax,# of bytes to allocate push ax call far malloc pop cx mov [bp+something],ax mov [bp+something+2],dx (malloc apparently returns its pointer in the ax & dx registers) Ok, so far, so good. However, sometimes the generated code looks like this: mov ax, # bytes push ax call far malloc pop cx cwd mov [bp+x],ax mov [bp+x+2],dx The 'cwd' instruction stands for convert word to double. In effect, it takes the value in the ax register and sign extends it into the dx register, convert- ing it from a signed 16 bit word (in ax) to a signed 32 bit word (in ax & dx). This is nifty (sarcasm intended) but it trashes the pointer returned by malloc before it has been stored! Moreover, the 'cwd' itself seems to be doing nothing useful. If I use my debugger to change the 'cwd' to a 'nop', my program works fine. This bug has defied all my attempts to work around it. I have tried all the memory models; I have tried it with optimization on and optimization off; I have tried rearranging the original source code and even putting the original source statements in separate, stand alone functions. Regardless of all tinkering, the malloc calls that worked originally still work and those that were originally broken stayed broken. Is this a known bug in Turbo C 1.5? Are there any patches/workarounds? Any suggestions at all? Reply by e-mail preferred, will summarize if sufficient interesting responses are sent. Thanks. Jim Hunt Intel Corp. "The company, as usual, disavows any knowledge of my actions."