file handling type confusion

[dixx]

Good morning!

I have trouble understanding the choice of C++ types used regarding file size and buffer size in IReadFile and IWriteFile.
It is clear to me why the amount of bytes to write or read must be given as an unsigned integer, but I fail to understand why the amount of bytes written or read will be returned as a signed integer. Especially troubling to me is that the actual file size is returned as a signed integer.

So here are my questions:
- Is it really possible to have irr::io::IWriteFile::write(...), irr::io::IReadFile::read(...) and irr::io::IReadFile::getSize() returning negative byte amounts?
- Wouldn't it be better to have irr::io::IReadFile::getSize() returning an unsigned long instead, so that I do not have to static_cast when I want to read a whole file?

Code: Select all

 
    irr::io::IReadFile* file = fileSystem_->createAndOpenFile( "fileName" );
    irr::u32 size = static_cast<irr::u32>( file->getSize() ); // I wish I would not have to cast here, it seems not logical to me
    irr::core::array<irr::c8> buffer( size + 4 ); // +4 to paranoia
    file->read( buffer.pointer(), size );
    file->drop();
  

Or did I get the whole thing wrong and it is much easier to read a whole file?

Please enlighten me. Thank you in advance!

Best Regards,
dixx

[CuteAlien]

This got partly changed in svn trunk. write and read do now return size_t. getPos and getSize still return long - the reason for that is what we get a long from ftell (which is most often used). So basically this goes back to the standard c library.

[dixx]

Ah, I see. Thank you for the quick reply and the clarification. Maybe it's worth a thought to update the Docs for ::getSize() with the return value -1L on error

[CuteAlien]

Yeah, right. Changed it in svn trunk (r5538). Thanks!

[masm32]

Hallo,
ich möchte auch mal meine 2 Worte dazu schreiben, da ich mich gerade sehr mit Irrlicht beschäftige.

Das der Rückgabewert negativ sein kann liegt daran, das es zu der Zeit als die C Libraries geschrieben wurden, keine so große Datenträger, als auch Dateizuordnungen gab. So konnte man mit negativen Werten Fehlercodes zurückgeben.

Wenn man statt der 32 Bit Werte lieber auf 64 Bit Werte geht, dann ist man für die Zukunft aufgestellt.

Der C89 und C99 Standard sagen, das long mindestens 32 Bit groß sein muss. Es ist aber nicht festgelegt, das long nicht auch größer sein kann.
Bei Microsoft Windows ist es tatsächlich so, das long einen 32 Bit großen Wert zurück gibt. Dafür hat Microsoft die Funktionen ftell, _ftelli64 sowie fseek und _fseeki64.
Bei Linux gibt es seit glibc 2.1 die Funktionen ftello und fseeko. Diese geben off_t bzw. haben off_t als Parameter, der 32 Bit groß ist.
Möchte man nun off_t mit 64 Bit größe haben, setzt man _FILE_OFFSET_BITS 64 und inkludiert dann stdio.h.

[CuteAlien]

Yeah, we got no 64-bit support there so far. So if you got files > 2GB it's probably going to be trouble currently.