Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!comp.vuw.ac.nz!mark From: mark@comp.vuw.ac.nz (Mark Davies) Newsgroups: comp.unix.bsd Subject: Re: New filesystem for BSD4.4 Date: 8 Jul 1993 21:40:14 GMT Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand. Lines: 28 Message-ID: <21i47u$6hs@st-james.comp.vuw.ac.nz> References: <C9BCvB.C3s@candle.uucp> <20m80k$e5t@st-james.comp.vuw.ac.nz> <32202@dog.ee.lbl.gov> NNTP-Posting-Host: bats.comp.vuw.ac.nz In article <32202@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes: >this sort of thing bit me, for instance, when trying to bring up >gdb (the current version of gdb was 4.4 at the time, oddly enough): >it had code of the form: > char *p = xmalloc(statbuf.st_size); >without a prototype for xmalloc(). This wound up malloc'ing 0 bytes >every time, as the code in xmalloc() was using the upper word of the >64-bit file size as if it were a simple 32-bit integer. This particular problem is quite common in lots of GNU code. A fairly typical sequence (this ones from bash) is: if (fstat (fd, &file_info) == -1) goto file_error_and_exit; string = (char *)xmalloc (1 + file_info.st_size); tresult = read (fd, string, file_info.st_size); which fails as Chris describes. Running gdb on 4.4 has another problem in that it has no support for displaying "long long" values so you can't actually look at your file_info.st_size value within the debugger to see its actual value. cheers mark