I apologise if it is a basic or silly question. What is the difference between char*
and LPSTR
. where the sizeof
both gives 4 bytes in my compiler. Can someone explain me in detail. thanks..

- 4,933
- 16
- 83
- 164
-
7`typedef CHAR *LPSTR;`, `typedef char CHAR;`. All you need to know about this stuff [on this page](http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx). – chris Aug 14 '12 at 04:56
-
@chris thanks for the reply but the need behind going for LPSTR and not using char * ? – 2vision2 Aug 14 '12 at 04:58
-
1As the answers say, it's purely historical. – chris Aug 14 '12 at 05:02
-
thanks for all your answers upvoted all.... – 2vision2 Aug 14 '12 at 05:14
3 Answers
LPSTR
is a Windows type, meant to be be the same regardless of what platform you were compiling on. It's a long pointer to a string.
Back in the days of segmented architecture (the old 64K segments, not the newer selector-based segmented memory), where you had tiny, small, medium, large and huge memory models, it was important that the Windows type was always the same, regardless of what type of pointer char *
was.
So, if you complied with different compilers where the underlying types were different, the windows.h
header file would define LPSTR
to compensate for that.
For example, Borland C may have had a sixteen-bit char *
and LPSTR
may have had to be defined as far char *
for it. In a compiler where char *
was already a long/far pointer, LPSTR
would have just used that instead.
Nowadays, with 32+ bit flat models, there is probably no real need for such shenanigans, though it may still happen with things like thunking between 64-bit and 32-bit code. Still, the types defined back then are still with us and still very much in use.
-
A small clarification on this.. what I understood is, in 32-bit and 64-bit machines LPSTR, PSTR and Char * are all mean the same and can be used interchangably? correct me if am wrong.. – 2vision2 Aug 14 '12 at 05:35
-
6@user1317084: No idea, and it really doesn't matter. You _should_ be using the type that the prototype uses. Even if the three types have converged into one, there's no guarantee that will remain so in future. The thing in particular I'd watch out for is 32-bit DLLs (for example) being called from 64-bit code (hence my thunking comment). Use the type that Windows API tells you to use, then you'll _know_ you're okay. – paxdiablo Aug 14 '12 at 05:40
Basically, the LP* pointers were to indicate to use a 32 bit pointer on 16 bit versions of Windows:
From WikiBooks
The letters "LP" or the prefix "lp" stands for "Long Pointer", which is exactly the same as a regular pointer on 32 bit machines. LP data objects are simply legacy objects that were carried over from Windows 3.1 or later, when pointers and long pointers needed to be differentiated. On modern 32-bit systems, these prefixes can be used interchangeably.

- 104,537
- 17
- 209
- 285
-
A small clarification on this.. what I understood is, in 32-bit and 64-bit machines LPSTR, PSTR and Char * are all mean the same and can be used interchangably? correct me if am wrong.. – 2vision2 Aug 14 '12 at 05:37
The difference is burried in the depths of time. LPSTR stands for "long pointer to string". Back before 32-bit processors, pointers to memory that might be in a different segment of memory (think, a long way away in memory), needed extra space to store.
On 32-bit (and later) processors, they're exactly the same thing. Microsoft uses LPSTR solely for historic reasons.

- 3,703
- 2
- 21
- 43
-
A small clarification on this.. what I understood is, in 32-bit and 64-bit machines LPSTR, PSTR and Char * are all mean the same and can be used interchangably? correct me if am wrong.. – 2vision2 Aug 14 '12 at 05:37
-
1That's correct. PSTR is typedefed to "char *", and will be the same on all architectures. LPSTR is typedefed to "far char *", so will be the same on 32-bit and beyond (since 'far' no longer means anything). They can be used interchangeably, but you're unlikely to see code using 'PSTR' any more, and you should generally follow the style of the code you're working with. – Martin Aug 14 '12 at 21:58