Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!hp-pcd!orstcs!go
From: go@orstcs.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Bug in Microsoft C 4.00?
Message-ID: <216700009@orstcs.UUCP>
Date: Sun, 15-Feb-87 03:13:00 EST
Article-I.D.: orstcs.216700009
Posted: Sun Feb 15 03:13:00 1987
Date-Received: Tue, 17-Feb-87 05:45:26 EST
References: <216700008@orstcs.UUCP>
Organization: Oregon State University - Corvallis, OR
Lines: 30
Nf-ID: #R:orstcs:216700008:orstcs:216700009:000:1341
Nf-From: orstcs!go    Feb 15 00:13:00 1987

Boy.  Sometimes I really goof up!

Regarging the "alleged" bug post of mine (for Microsoft C V4.00), please
note that I goofed.
 
Before all you good people fill my mailbox with "...you stupid idiot.."
I should point out (as someone just did to me..) that there is a GROSS
mistake on my part in my bug post.  The test programs given work just
fine when one considers that (red face inserted here) array+sizeof(..)
is not the same as (char *) (array) + sizeof(.) in the case where array is
an int array.  Boy, I feel stupid.

Anyway, the attempt was to show a bug (which I cannot seem to demonstrate
with a simple program) that caused two arrays to share space.  In the
real program, array1 was a character array of text strings and
array2 was an array of pointer-to-structures in another module that
was being initialized to NULL pointers.  When array2 was an
automatically (linker) created array, the initialization left the
text string array full of double-nulls.  When I simply added a
"= {0}" initialization to array2 (of pointers), the problem went away.

No, there were no fancy pointer manipulations here.  Everything
was being done with "array[subscript] = NULL;" inside a "for"
loop.

I'll keep my trap (and keyboard) shut until I find a suitably short
(reliable) demonstration of the bug.

Gary Oliver
...!hplabs!hp-pcd!orstcs!go