strncpy not behaving

[mohammadalipak]

strncpy is not working for me for the following variable. It is working fine elsewhere in the program.

char     szQName[21];
strncpy(szQName, "Text", 20);

//debugger shows szQName's value as -88D11B47-8F19-41CA-.

Has it ever happened to anyone?Details (context of the code):

char     szQName[21];
LPSTR    szFileName;   //Long Pointer to a STRing (char*)

szFileName = malloc(256*sizeof(char));

GTGetUniqueFileName ("", "txt", "TXT", (LPSTR)szFileName);
//now szFileName = TXT-88D11B47-8F19-41CA-B586-9541BAD87CC4.txt

strncpy(szQName, "Text", 20);
//szQName = -88D11B47-8F19-41CA-

why?

[Salem]

Post a complete program which we can all compile, which produces the errors which you see.

There could be any number of reasons, anywhere in the code which could cause this effect. As soon as you trash memory, then anything can happen, including working for a while, producing garbage, then finally dying (as seems to be the case here).

Also, why are you casting in the call to GTGetUniqueFileName and do you have an online reference manual for it?

[mohammadalipak]

I'm sorry to say that posting the whole source code wouldn't help, 'cuz:It's quite long
It cannot compile without 10s of header files & Oracle's JDEdwards Software.
But I can show you the contigious segment where the error occurs.
(I'm casting the LPSTR 'cuz I saw some other APIs doing the same. And no there is no reference manual (that I know of) for GTGetUniqueFileName() - neither online nor offline).

int     iMemorySize = 0;
int     iTotal = 0;
char*   pCursor;
void*   pHead;
char    szQName[21];
FILE*   pFile;
LPSTR   szFileName; //#define LPSTR char*

szFileName = malloc(30000*sizeof(char));

iMemorySize = 24+moTextSize; //moTextSize is int

pHead = malloc(iMemorySize);
pHead = memcpy (pHead, lpSource, 24+moTextSize);//lpSource points to a data structure

GTGetUniqueFileName ("", "txt", "TXT", (LPSTR)szFileName++);//szFileName is returned as "\TXT-somename-123.txt" hence the ++ to get rid of "\"

pFile = fopen (strcat("\\\\JDEDEP\\B7333\\MEDIAOBJ\\TEXT\\", szFileName), "w");
fprintf (pFile, szNewMessage);
fclose (pFile);

strncpy(szQName, "Text", 20);//szQName now equals "-somename-" instead of "Text"

If you think looking at the whole program would still help, you can look at the attachment.

[TkTkorrovi]

Try to comment out the suspicious code, like that containing GTGetUniqueFileName, and see whether it works then. To comment out you may use something like #if 0 and #endif Or, try to temporarily substitude the suspicious code with something not suspicious.

[Salem]

Already I see a whole host of problems coming out of the woodwork.
No wonder you're getting a myriad of obscure effects.

Essentially, you've been accumulating bugs without realising it. Now you have a bug-ridden large program and it's reached a critical mass where any attempt to add new code or fix a bug merely shows up another bug.

Here are some of the problems
> szFileName++
This was pointing at some allocated memory, but it isn't any more.
When you get around to free(szFileName) , you've introduced a bug into your memory allocator.

> strcat("\\\\JDEDEP\\B7333\\MEDIAOBJ\\TEXT\\", szFileName)
String constants are supposed to be read-only, yet you're trying to append data to it. On real operating systems, this would cause an immediate segmentation fault.
On your machine, it just roams through memory getting longer and longer,
so "\\\\JDEDEP\\B7333\\MEDIAOBJ\\TEXT\\"
becomes "\\\\JDEDEP\\B7333\\MEDIAOBJ\\TEXT\\foo"
becomes "\\\\JDEDEP\\B7333\\MEDIAOBJ\\TEXT\\foofoo"
becomes "\\\\JDEDEP\\B7333\\MEDIAOBJ\\TEXT\\foofoofoo" and so on until it eventually trashes some other memory.

String constants are initialised only ONCE (when the program is loaded). If you mess with them, they're changed for good. They're not automatically reset every time the line of code which refers to them is executed, so if your "Hello" has been trashed into "World" by the time you come to copy it, then "World" is what you'll get, no matter what the source code says.

So even though you may be doing strncpy(szQName, "Text", 20); , because "Text" is stored in the same kind of memory as the string you're abusing with strcat, you're going to end up with something completely different.

If this bug-rate is replicated in the rest of your large program, I'd be shocked that you got this far TBH.

Personally, given your use of strcat, and general pointer abuse, I would be recommending you re-learn C.

> I'm casting the LPSTR 'cuz I saw some other APIs doing the same.
Bad idea. Indiscriminate casting reduces the ability of the compiler to warn you when you're doing something wrong. If your code is correct, then you shouldn't need to cast it.

[mohammadalipak]

Thanks a bunch. My program works now. I just fixed my strcat - made a variable instead of concatenating the constant string.
I was wondering if free(--szFileName) would solve the issue. And yeah, you got that right. I really need to re-learn C.