0

The line

std::unique_ptr<PHYSFS_sint64> myBuf(new PHYSFS_sint64[PHYSFS_fileLength(myfile)]);

produces the warning

warning C4244: 'initializing' : conversion from 'PHYSFS_sint64' to 'unsigned int', possible loss of data

PHYSFS_sint64 is a typedef for singed long long

PHYSFS_fileLength returns a PHYSFS_sint64.

So I don't understand why the compiler tries to convert from signed long long to unsigned int when I just try to assign a signed long long to a signed long long?

When I explicitly type signed long long instead of PHYSFS_sint64 it still outputs the same warning

Am I being stupid right now? I don't get it

A. D.
  • 728
  • 1
  • 9
  • 27
  • 4
    This unique pointer will call the wrong `delete` on destruction, which causes undefined behaviour. – Kerrek SB Dec 14 '15 at 14:26
  • @KerrekSB Could you elaborate please? I replaced the raw pointer that I was previously using with `unique_ptr` because I read it's safer. I thought I don't need to worry about deleting when using a `unique_ptr`? – A. D. Dec 14 '15 at 14:27
  • Is there a reason you're not using `std::vector`? – TartanLlama Dec 14 '15 at 14:30
  • 4
    You are using `std::unique_ptr` when you should be using `std::unique_ptr`. – Some programmer dude Dec 14 '15 at 14:34
  • TartanLlama: Yep. It's because I don't know how to use it in this case :P JoachimPileborg: Thanks, got it! – A. D. Dec 14 '15 at 14:34
  • Also, just to experiment and to help you understand *where* the problem actually is, can you try doing just e.g. `new PHYSFS_sint64[PHYSFS_fileLength(myfile)]`? Does that give you the same warning? – Some programmer dude Dec 14 '15 at 14:37

2 Answers2

2

You haven't really given enough information, but the likely explanation is that size_t (the type used to represent the range of array indexes and sizes supported by your implementation) is a 32-bit quantity. Which means, to use a 64-bit integer (signed or not) as an array size, your compiler would convert it to 32-bit in some manner.

If this is correct, you will find that size_t and unsigned int with your compiler are the same (which the standard permits but does not require), and both are a 32-bit type (which, again, are permitted but not required). Which probably all means you are using a 32-bit implementation.

An alternative - but highly unlikely - explanation is that you have a buggy compiler which does not handle the standard conversions between integral types of different sizes correctly in expressions. I say unlikely, as a compiler with such bugginess is more likely to produce faulty executable code without a whimper, rather than giving warnings about it.

Peter
  • 35,646
  • 4
  • 32
  • 74
  • I'm not going to lose sleep over someone downvoting this, but an explanation of why might be informative. – Peter Dec 15 '15 at 09:58
0

Here is the problem [PHYSFS_fileLength(myfile)]...

You are using it as an index (or size of array). Indices,sizes are unsigned. Usually (I said usually because I am not sure about all cases), indices are size_t which is platform dependable but it is always unsigned

Humam Helfawi
  • 19,566
  • 15
  • 85
  • 160
  • Welcome, for sizes and indices you may use size_t always which will reduce much overhead.... – Humam Helfawi Dec 14 '15 at 14:39
  • Except for the fact that iterator arithmetic is defined on `ptrdiff_t`, so while you can write `v[uns]`, you can't write `*(v.begin() + uns)` without getting a "converting from unsigned to signed" warning. – Michael Karcher Dec 14 '15 at 15:29