Can the following code run on 64bit system?

Question

0.00/5 (No votes)

See more:

I am trying to ensurs that my codes can run on both 32bit and 64bit systems.Please can the following code *run compile on 64bit compiler*? If no, can someon show me a modified version that can * complile on 64bit compiler*?The code is:

C++

INT_PTR GetShortPath( THAR *szFullPath, TCHAR *pszShortPath, INT_PTR iStrlen)
{
     if(!lstrlen(pszFullPath))
      {
          return (INT_PTR)FALSE;
       }
      
     TCHAR *p, *q;
      p = pszFullPath, q = pszShortPath;
      INT_PTR I = 0;
      while(*p)
      {
          *q = *p;
           p++,q++;
    
       }
       while(*p != T('\\'))
       {
          if( I   <  iStrlen)
            {
                *q = *p;
               p++, q++,I++;
           }
           else
           {
              return (INT_PTR)FALSE;
            }
        }
        *q = T('\0');
        return (INT_PTR)TRUE;
}

Posted 18-Feb-14 6:19am

Gbenbam

Updated 18-Feb-14 9:00am

v9

Add a Solution

Comments

Sergey Alexandrovich Kryukov 18-Feb-14 12:51pm

Why won't you compile, execute it and find out? From the first glance, I cannot see why not...
—SA

Gbenbam 18-Feb-14 13:44pm

Please see if you can react to my latest comments.

Gbenbam 18-Feb-14 14:16pm

I apologise for bordering you.The comment I wanted you to see was not submitted to the server.But I have embedded it in the reply to the last comment.

W∴ Balboos, GHB 18-Feb-14 13:01pm

The only thing that comes to mind as to why the poser would bring up this question is the use of his predefined types, such as INT_PTR. He's incrementing a pointer in his while-loop.

A solution would be to compile separate 32 & 64 bit versions to handle the difference.

Gbenbam 18-Feb-14 13:44pm

Please see if you can react to my latest comments.

Gbenbam 18-Feb-14 14:16pm

I apologise for bordering you.The comment I wanted you to see was not submitted to the server.But I have embedded it in the reply to the last comment.

KarstenK 18-Feb-14 13:24pm

it should work "as designed" but void bugs :-O

while(*p)
{
*q = *p;
p++,p++;//really ???

}

Sergey Alexandrovich Kryukov 18-Feb-14 13:46pm

Yee...
(It looks like it's fixed by now...)
—SA

Gbenbam 18-Feb-14 13:49pm

I have made appropriate correction.See if you have anything more to say.My attention is actually the pointer arithmetic.

Suppose I use:
p + 1; q+ 1

instead of:
p++, q++;

would it work?

Matt T Heffron 18-Feb-14 13:56pm

Nope,
p = p + 1; q = q + 1;
would be the way.
p++;
q++;
I++;
is fine (and preferred over the above)

Matt T Heffron 18-Feb-14 13:53pm

I don't see any reason for using INT_PTR in this code.
The function clearly should return bool, and the INT_PTR iStrlen and INT_PTR I both could be simple int, as no path is going to exceed the capacity of an int and they are NOT pointers.
Beyond that, I think the comment above is correct: compile separate 32 bit and 64 bit versions. IF there are other parts of the application that require 64 bit. Otherwise, 32 bit apps *should* run correctly on 64 bit Windows. Lots of them already do!

Gbenbam 18-Feb-14 14:12pm

Then what is the big deal about the _PTR typed. What on earth is there advange and when are they used.Can someone please explain the big point about the _PTR types to me.I read a lot of microsoft's documentation on them espcially the guide to 64bit programming.It says in that all pointers are 64bits on 64bits system and during pointer arithmetic there should be a cast to _PTR types.Why can't I simply continue to use my good old 32bit data types and expect them to run on 64bit systems?

W∴ Balboos, GHB 18-Feb-14 14:24pm

Defined types are a way to build code that will run, upon recompilation, on various platforms.
It happens, in a way, already: if you use type int, its size depends upon you compiler. It once was 16bits, now its more commonly 32 or 64 bits. It implies the width of the native data size for the compilation.

If you require a specific size, then you use specific declarations byte,short,int, long int, etc. This is taken into account when incrementing a pointer, as well.

What the defined values do for you, in a nutshell, is map values to the appropriate sized items for a given compiler.

[no name] 18-Feb-14 16:21pm

The "_PTR" types (like DWORD_PTR) are useful in APIs where the meaning of the value is user-defined. Several Windows APIs allow storing a user defined data value. This could be an integer or a pointer. Trying to store a 64 bit pointer in a 32 bit DWORD won't work. DWORD_PTR takes care of that. Examples:

ComboBox, ListBox, ListCtrl, TreeCtrl.

http://msdn.microsoft.com/en-us/library/43y9kx83.aspx
http://msdn.microsoft.com/en-us/library/287styts.aspx

Gbenbam 18-Feb-14 14:23pm

Sorry My emphasia is not running on 64 bit but being able to compile to to a 64 bit code

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Stefan_Lang · Answer 1 · 2014-02-19T00:42:00

This code contains the following errors:

1. The return value type is a boolean value. Use type bool (and the values true and false, rather than TRUE and FALSE). If the return value is passed to a system function, you may need to use BOOL instead

2. the variables iStrlen and I are used as subscript into an array. They should be defined as std::size_t. You can use SIZE_T instead, which is the MS-Version of the same type, but their inability to define and use types properly has already been sufficiently documented by the fact they needed to introduce the *_PTR types - so why bother with unreliable type definitions when you can use standardized types?

3. Literals of type TCHAR need to be defined using the _T() macro, not T(). You are missing the leading underscores.

Fixed those types and values for you:

C++

bool GetShortPath( THAR *szFullPath, TCHAR *pszShortPath, std::size_t iStrlen) //fixed
{
     if(!lstrlen(pszFullPath))
      {
          return false;//fixed
       }
      
     TCHAR *p, *q;
      p = pszFullPath, q = pszShortPath;
      std::size_t I = 0;//fixed
      while(*p)
      {
          *q = *p;
           p++,q++;
    
       }
       while(*p != _T('\\'))//fixed
       {
          if( I   <  iStrlen)
            {
                *q = *p;
               p++, q++,I++;
           }
           else
           {
              return false;//fixed
            }
        }
        *q = _T('\0');//fixed
        return true;//fixed
}

Please note that you should always use the correct type - else you might just be using no type at all and program in Assembler!

Don't use the MS types unless you really, really must (i. e. you're interfacing to system functions that require them, or using a proprietary type definition such as TCHAR).