MS-DOS with Micro$oft 'C' 6.0 and Micro$oft 7.01 compilers
MS-DOS with Borland Turbo-C 3.0
VAX/VMS VAX-C V3.0
It just waits in a CPU-eating race on SunOs 5.5.1
With glibc on Linux, it seg-faults.
This is not meant to be flame-bait. I know this is not how to
write code. However, the effect of this kind of coding does
happen when structures containing file-pointers are duplicated
so it can (does) happen.
Glibc doesn't check the contents of the FILE structures, just
the addresses and since it "knows" the pointer received was not
one it provided, it generates signal 11 on its own. Is this
REALLY what is supposed to happen? After all, the function call
did get a perfectly valid pointer to the required structure.
#include <stdio.h>
FILE here;
int main()
{
FILE *file;
if((file = fopen("/tmp/foo", "w")) == NULL)
exit(1);
memcpy(&here, file, sizeof(FILE));
if((memcmp(&here, file, sizeof(file))) == 0)
fprintf(stdout, "FILE structure contents are correct\n");
/*
This will seg-fault. fprintf() gets a provably (proof above) valid
pointer of type FILE.
*/
fprintf(&here, "Hello world!\n");
fclose(file);
return 0;
}
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.123 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/