java - DataInputStream available() behaviour for reading files bigger than Integer.MAX_VALUE bytes -
i have binary file in custom format have written using dataoutputstream. simplified format of data in file is: intcharintcharintchar...intchar
i using datainputstream read file, , available() determine whether or not next read successful.
everything works fine small files. however, big files, filesize bigger integer.max_value bytes, available() call returns strange negative values after first read. file trying read 4751054632 bytes (about 4.8 gig).
simplified test code:
datainputstream reader=new datainputstream(new bufferedinputstream(new fileinputstream("/path/file"))); system.out.println("available @ start:\t" + reader.available()); while(reader.available()>0){ int a=reader.readint(); system.out.println("available after readint:\t" + reader.available()); char b=reader.readchar(); system.out.println("available after readchar:\t" + reader.available()); //do }
output:
available @ start: 2147483647 //this equal integer.max_value available after readint: -2147475461 available after readchar: -2147475463
instead of using available() execute readint() , readchar() commands in try block , catch exception when file finished, trying understand why behaviour happening. looking method return true if there data available read , false if file finished/ stream has ended. thought available()>0 guess not?
i using datainputstream read file, , available() determine whether or not next read successful.
then you're doing wrong. see javadoc: "returns estimate of number of bytes can read (or skipped over) input stream without blocking next invocation of method input stream.". many implementations returns zero, , ones don't return 0 don't guarantee return positive number: can't, when number concerned exceeds integer.max_value.
also, size of file change between available()
, read().
you should detect end of stream catching eofexception
on methods throw it, or -1 or null
returned methods don't (i.e. read()
, overloads, , readline()
respectively).
Comments
Post a Comment