Yes, this is roughly how one might implement Pascal-style insert on C-style NUL-terminated strings. I would point out, however, that in the Pascal world, strings were normally counted rather than NUL-terminated, and if you're thinking in Pascal, you might be inclined to subtly make assumptions that do not hold on counted strings, either relatively benign — such as the matter of forgetting that strlen() is not an O(1) but O(n) operation — or potentially dangerous — such as accidentally shoving terminators into your not-8-bit-clean strings. I would also point out that in Pascal, it was customary to number chars of a string from 1 onwards; you're interpreting pos in C style, so this being an inconsistency with the concept of a 'Pascal-style' insert, it would definitely merit a brief mention in documentation, such as a helpful comment above the function.

Edward is right about #insert <string.h> et al over #insert "string.h". I would disagree with him regarding "error checking"; in the context of Pascal-style string processing, these are boundary conditions, not errors, and if you're seeking to have a Pascal-style insert, you probably don't care about getting error codes for these conditions from your function, so it would be a waste of brain power to invent and remember encoding system for them. HOWEVER, you're treating the case of pos lying far left or far right of *pStr in two different ways: in the first case, you're not inserting anything, and in the second case, you're inserting pWord at the right end of *pStr. It is likely that consistency would be preferable here, either inserting in both cases or not inserting in either cases, unless you desire bug-compatibility with some particular pre-existing implementation.

As for Edward's recommendation of realloc() over malloc() — I would advise against it unless you find your system is running too slowly in practice. Premature optimisation is the root of all evil. Memory fragmentation of the kind you might get by calling malloc() is not a real issue in modern computer systems with paged virtual memory.

Besides the Hungarian notation, which I also recommend against, unless you're labouring under a code style guide that mandates it — it's bad but probably not worth a revolt —, there's another stylistic quirk in your code that slightly bothers me: you're typecasting the result of malloc() explicitly to (char *). This idea comes from a bunch of old — as in nineties — compilers for a weird language called "C/C++", which mixed ideas from C and C++. Real C does not need this typecast because in C, void * and char * are compatible; C++ needed it and so did the straddling "C/C++" compilers, but you would be using new char[...] (or quite possibly, new std::string(...)) if you were programming in real C++. So, I'm inclined to suggest you take out the typecast.

And finally, if you're using malloc() and free(), you'll need #include <stdlib.h>. You might get by the compiler without making it explicit, but it's generally considered a good practice to explicitly include headers for all the functions and types you directly refer in your code.

Yes, this is roughly how one might implement Pascal-style insert on C-style NUL-terminated strings. I would point out, however, that in the Pascal world, strings were normally counted rather than NUL-terminated, and if you're thinking in Pascal, you might be inclined to subtly make assumptions that do not hold on terminated strings, either relatively benign — such as the matter of forgetting that strlen() is not an O(1) but O(n) operation — or potentially dangerous — such as accidentally shoving terminators into your not-8-bit-clean strings. I would also point out that in Pascal, it was customary to number chars of a string from 1 onwards; you're interpreting pos in C style, so this being an inconsistency with the concept of a 'Pascal-style' insert, it would definitely merit a brief mention in documentation, such as a helpful comment above the function.

Edward is right about #insert <string.h> et al over #insert "string.h". I would disagree with him regarding "error checking"; in the context of Pascal-style string processing, these are boundary conditions, not errors, and if you're seeking to have a Pascal-style insert, you probably don't care about getting error codes for these conditions from your function, so it would be a waste of brain power to invent and remember encoding system for them. HOWEVER, you're treating the case of pos lying far left or far right of *pStr in two different ways: in the first case, you're not inserting anything, and in the second case, you're inserting pWord at the right end of *pStr. It is likely that consistency would be preferable here, either inserting in both cases or not inserting in either cases, unless you desire bug-compatibility with some particular pre-existing implementation.

As for Edward's recommendation of realloc() over malloc() — I would advise against it unless you find your system is running too slowly in practice. Premature optimisation is the root of all evil. Memory fragmentation of the kind you might get by calling malloc() is not a real issue in modern computer systems with paged virtual memory.

Besides the Hungarian notation, which I also recommend against, unless you're labouring under a code style guide that mandates it — it's bad but probably not worth a revolt —, there's another stylistic quirk in your code that slightly bothers me: you're typecasting the result of malloc() explicitly to (char *). This idea comes from a bunch of old — as in nineties — compilers for a weird language called "C/C++", which mixed ideas from C and C++. Real C does not need this typecast because in C, void * and char * are compatible; C++ needed it and so did the straddling "C/C++" compilers, but you would be using new char[...] (or quite possibly, new std::string(...)) if you were programming in real C++. So, I'm inclined to suggest you take out the typecast.

And finally, if you're using malloc() and free(), you'll need #include <stdlib.h>. You might get by the compiler without making it explicit, but it's generally considered a good practice to explicitly include headers for all the functions and types you directly refer in your code.

Yes, this is roughly how one might implement Pascal-style insert on C-style NUL-terminated strings. I would point out, however, that in the Pascal world, strings were normally counted rather than NUL-terminated, and if you're thinking in Pascal, you might be inclined to subtly make assumptions that do not hold on counted strings, either relatively benign — such as the matter of forgetting that strlen() is not an O(1) but O(n) operation — or potentially dangerous — such as accidentally shoving terminators into your not-8-bit-clean strings. I would also point out that in Pascal, it was customary to number chars of a string from 1 onwards; you're interpreting pos in C style, so this being an inconsistency with the concept of a 'Pascal-style' insert, it would definitely merit a brief mention in documentation, such as a helpful comment above the function.

Edward is right about #insert <string.h> et al over #insert "string.h". I would disagree with him regarding "error checking"; in the context of Pascal-style string processing, these are boundary conditions, not errors, and if you're seeking to have a Pascal-style insert, you probably don't care about getting error codes for these conditions from your function,, so it would be a waste of brain power to invent and remember encoding system for them. HOWEVER, you're treating the case of pos lying far left or far right of *pStr in two different ways: in the first case, you're not inserting anything, and in the second case, you're inserting pWord at the right end of *pStr. It is likely that consistency would be preferable here, either inserting in both cases or not inserting in either cases, unless you desire bug-compatibility with some particular pre-existing implementation.

As for Edward's recommendation of realloc() over malloc() — I would advise against it unless you find your system is running too slowly in practice. Premature optimisation is the root of all evil. Memory fragmentation of the kind you might get by calling malloc() is not a real issue in modern computer systems with paged virtual memory.

Besides the Hungarian notation, which I also recommend against, unless you're labouring under a code style guide that mandates it — it's bad but probably not worth a revolt —, there's another stylistic quirk in your code that slightly bothers me: you're typecasting the result of malloc() explicitly to (char *). This idea comes from a bunch of old — as in nineties — compilers for a weird language called "C/C++", which mixed ideas from C and C++. Real C does not need this typecast because in C, void * and char * are compatible; C++ needed it and so did the straddling "C/C++" compilers, but you would be using new char[...] (or quite possibly, new std::string(...)) if you were programming in real C++. So, I'm inclined to suggest you take out the typecast.

And finally, if you're using malloc() and free(), you'll need #include <stdlib.h>. You might get by the compiler without making it explicit, but it's a good practice to include it explicitly anyway.

Yes, this is roughly how one might implement Pascal-style insert on C-style NUL-terminated strings. I would point out, however, that in the Pascal world, strings were normally counted rather than NUL-terminated, and if you're thinking in Pascal, you might be inclined to subtly make assumptions that do not hold on counted strings, either relatively benign — such as the matter of forgetting that strlen() is not an O(1) but O(n) operation — or potentially dangerous — such as accidentally shoving terminators into your not-8-bit-clean strings. I would also point out that in Pascal, it was customary to number chars of a string from 1 onwards; you're interpreting pos in C style, so this being an inconsistency with the concept of a 'Pascal-style' insert, it would definitely merit a brief mention in documentation, such as a helpful comment above the function.

Edward is right about #insert <string.h> et al over #insert "string.h". I would disagree with him regarding "error checking"; in the context of Pascal-style string processing, these are boundary conditions, not errors, and if you're seeking to have a Pascal-style insert, you probably don't care about getting error codes for these conditions from your function, so it would be a waste of brain power to invent and remember encoding system for them. HOWEVER, you're treating the case of pos lying far left or far right of *pStr in two different ways: in the first case, you're not inserting anything, and in the second case, you're inserting pWord at the right end of *pStr. It is likely that consistency would be preferable here, either inserting in both cases or not inserting in either cases, unless you desire bug-compatibility with some particular pre-existing implementation.

As for Edward's recommendation of realloc() over malloc() — I would advise against it unless you find your system is running too slowly in practice. Premature optimisation is the root of all evil. Memory fragmentation of the kind you might get by calling malloc() is not a real issue in modern computer systems with paged virtual memory.

Besides the Hungarian notation, which I also recommend against, unless you're labouring under a code style guide that mandates it — it's bad but probably not worth a revolt —, there's another stylistic quirk in your code that slightly bothers me: you're typecasting the result of malloc() explicitly to (char *). This idea comes from a bunch of old — as in nineties — compilers for a weird language called "C/C++", which mixed ideas from C and C++. Real C does not need this typecast because in C, void * and char * are compatible; C++ needed it and so did the straddling "C/C++" compilers, but you would be using new char[...] (or quite possibly, new std::string(...)) if you were programming in real C++. So, I'm inclined to suggest you take out the typecast.

And finally, if you're using malloc() and free(), you'll need #include <stdlib.h>. You might get by the compiler without making it explicit, but it's generally considered a good practice to explicitly include headers for all the functions and types you directly refer in your code.