Hi,
I am porting a 32-bit application to 64-bit application (AMD).
I am getting the error:


XXX.cpp(49) : warning C4267: '=' : conversion from 'size_t' to 'long',
possible loss of data
XXX.cpp(84) : error C2664: 'HRESULT BinValue::get(const unsigned char
*&,long &)' : cannot convert parameter 1 from 'unsigned char *' to
'const unsigned char *&'
Conversion loses qualifiers
NMAKE : fatal error U1077: 'cl' : return code '0x2'


In 64 bit AMD programming the data type unsigned INT_PTR (unsigned
int*) is UINT_PTR and for unsigned LONG_PTR (unsigned long*) is
ULONG_PTR. What should be the data type for unsigned char* ????
Respects,
Saurabh Aggrawal
Sr. S/w Programmer


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Saurabh Aggrawal wrote:

 > I am porting a 32-bit application to 64-bit application (AMD).
 > I am getting the error:

 > XXX.cpp(49) : warning C4267: '=' : conversion from 'size_t' to
'long',
 > possible loss of data

Without knowing the actual type of size_t, it's difficult to say. On
most machines I use, it is either unsigned long, or unsigned int with
unsigned int the same size as unsigned long.  Which means that all of
the values in a size_t are NOT representable in a long.  If the
compiler
is warning about converting from size_t to long, it would warn on all
of
the machines.

I suspect that you are either using a newer (or different) compiler, or
different options, and that there is nothing here that wasn't in the
code before.  In fact, the probability of it really being a problem is
almost certainly far less on the 64 bit machine.

 > XXX.cpp(84) : error C2664: 'HRESULT BinValue::get(const unsigned char
 > *&,long &)' : cannot convert parameter 1 from 'unsigned char *' to
 > 'const unsigned char *&'
 > Conversion loses qualifiers
 > NMAKE : fatal error U1077: 'cl' : return code '0x2'

Since I can't see all of the data involved (declaration of
BinValue::get, the calling expression, and the declaration of all of
the
variables in the calling expression), it's difficult to say.  If the
first parameter is an unsigned char* however, the code is, or should be
illegal; if the first parameter is an lvalue (which I suppose it is),
then allowing the binding would create a loop-hole in the type system,
whereby you could write modifications to const variables without an
intervening const_cast.  IMHO, the text in �8.5.3/4 doesn't make this
really clear, but basically, if constness is to be significant, the
rules here have to be pretty much the same as if the reference were a
pointer, and we took the address of its parameter.  And assigning an
"unsigned char**" to an "unsigned char const**" is definitly illegal,
see �4.4/4.

In sum, your problems (as far as I can tell) have nothing to do with
porting to 64 bits -- and they should have been detected with a 32 bit
compiler as well.

 > In 64 bit AMD programming the data type unsigned INT_PTR (unsigned
 > int*) is UINT_PTR and for unsigned LONG_PTR (unsigned long*) is
 > ULONG_PTR. What should be the data type for unsigned char* ????

I'm afraid I don't see what you're saying.  The data type for an
unsigned char* is "unsigned char*".

Without knowing more about what BinValue::get is supposed to do, and
how
it is being called, it is impossible to say more, but off hand, unless
the error message from the compiler is completely off base (which
happens more often that I would like), the code is simply illegal, and
shouldn't compile with any C++ compiler.  What you may be seeing (but
attention, this is just guessing on my part) is that the first
parameter
to BinValue::get isn't actually modified (and logically, should be a
value, or at least a reference to const), and that earlier compilers
were converting the unsigned char* to an unsigned char const* (a legal
conversion), and binding the resulting temporary to the reference;
binding a temporary to a reference to non-const is illegal according to
the standard, but was allowed up by the language up through the late
1980's, and is still allowed by many compilers in order to avoid
breaking older code.  (IMHO, a good compiler will allow it, at least
with some sort of compatibility options, but it will also emit a
warning.)

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Saurabh Aggrawal wrote:
 > XXX.cpp(84) : error C2664: 'HRESULT BinValue::get(const unsigned char
 > *&,long &)' : cannot convert parameter 1 from 'unsigned char *' to
 > 'const unsigned char *&'

This error has nothing to do with 32/64 bit portability. It's plain
wrong to convert a T* (whatever T is) to a const T*&. This case is
similar to the case of converting T* to const T** described in the FAQ:
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.15

HTH,

Alberto

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

"Saurabh Aggrawal" <games60@hotmail.com> wrote in message
news:1102593033.538746.187980@f14g2000cwb.googlegroups.com...
 > In 64 bit AMD programming the data type unsigned INT_PTR (unsigned
 > int*) is UINT_PTR and for unsigned LONG_PTR (unsigned long*) is
 > ULONG_PTR. What should be the data type for unsigned char* ????

a) This is very much system specific and would be better asked in a
system specific group.

b) Assuming you are talking about Windows you have misunderstood the
data types.
INT_PTR is not a pointer to an int, it's an int big enough to hold a
pointer.
Similarly for the other _PTR types.
If you look in MSDN you'll find:
     Signed integral type for pointer precision. Use when casting a
pointer to an integer to perform pointer arithmetic.
So the type to use for unsigned char* depends on what you want to do
with it.
The first question you should ask is: why not use 'unsigned char *'.
Generally speaking the only reason for using the _PTR type is because
you have an API that manages a pointer as a number, without
considering it to be a pointer.
In which case the type to be used is determined by the API.
For your own code, just leave it as the pointer that it is.

For VC++ in 32 bit LONG_PTR equates to long and INT_PTR equates to
int, both of which are 32 bit signed integers.
For VC++ in 64 bit they are both __int64.
The U variants are the same but with an unsigned qualifier
(digression: is unsigned a qualifier or part of the type name?).
Again, they specify the size of an unsigned int big enough to hold a
pointer, not the size of a pointer to an unsigned thing.

-- 
J.T.
Please reply via the newsgroup.



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Saurabh Aggrawal wrote:
[snip]
> XXX.cpp(84) : error C2664: 'HRESULT BinValue::get(const unsigned char
> *&,long &)' : cannot convert parameter 1 from 'unsigned char *' to
> 'const unsigned char *&'
> Conversion loses qualifiers
[snip]
You may want to look at the thread "interface problem in gcc"
as the problem is the same. A "reinterpret_cast<const unsigned
char*&>(.)" will most likely do, but it invokes undefined
behaviour, so I would consider it a temporary solution, i.e.
if you don't have the time to deal with the problem properly
use the cast and add a comment.

Regards,
Vladimir Marko


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]