Remake `IODevice` from `int` to `size_t` about clanlib HOT 5 CLOSED

I would be happy to change int to size_t. Although I don't plan to use greater than 2^31 sized files, I cannot see any disadvantages in changing it.

from clanlib.

I don't mind such a change, although it should be noted that if you use size_t then 32-bit builds will still not be able to handle files greater than 2^32. One could argue that int64_t is the better choice.

from clanlib.

Thanks for the opinions. I suggest to stop on size_t. A 32-bit program probably does not need to open files larger than 2 ^ 32, since it can not address so much memory.

In fact, I am motivated by a simpler goal. Some code analyzer gives me warnings that using a signed type for the size is unsafe and I agree with this, although in practice it is still now unlikely. :)

Today or tomorrow I will offer a commit for review.

from clanlib.

Report about pull request

I started with IODevice.cpp and remade from int to size_t all the related files. Into subsection core/zip did not dive, limited to cosmetics at the interface level. Although there is an unsafe code, for example - forced conversion from int64_t to int:

     int64_t pos;
     ...
     int ZipIODevice_FileEntry::get_position() const
	{
		return (int)pos;
	}

I do not use zip and will not be able to test its performance. At least it became no worse.

Also did not touch the seek functions. Their change is non-trivial and requires separate testing and experience of WinAPI (and others OS). As result - and early and now it is impossible to move the pointer in the file more than 2^31 bytes.

Further, thanks to the code analyzer (PVS) was convinced that it had not added any new problems, and also slightly improved the existing code in the changed files to exclude the following warnings:

• V676. It is incorrect to compare the variable of BOOL type with TRUE.
  https://www.viva64.com/en/w/v676/print/

• V688. The 'foo' local variable possesses the same name as one of the class members, which can result in a confusion.
  https://www.viva64.com/en/w/v688/print/

• V690. The class implements a copy constructor/operator=, but lacks the operator=/copy constructor.
  https://www.viva64.com/en/w/v690/print/

• V730. Not all members of a class are initialized inside the constructor.
  https://www.viva64.com/en/w/v730/print/

In conclusion, compiled all the examples (45/47 successful, 2 - I have no "assimp/cimport.h" for Object3D and Quaternion) and made sure that they did not crush. The examples "Layered Window" and "Layered Window 2" crashes with OpenGL INVALID_ENUM but it had chashed before my changes too. And finally test my own project, which actively uses file.read() and write(). No problems detected.

from clanlib.

Found a small problem to fix in the next commit:
File iodevice_provider.h, overdid with copy-pase:

virtual size_t receive(void *data, **size_t size_t**, bool receive_all = true) = 0;
virtual size_t peek(void *data, **size_t size_t**) = 0;

In .cpp all is correct size_t len

from clanlib.