On 05/18/2018 09:30 AM, Andreas Schnellbacher wrote:
I've tried to write a function that should convert each zero char into a
dot. The following function doesn't work and I don't know why.
It is because you are removing the string terminator.
You need to add a terminator to each string where you replace the
terminator so that downstream string processing works as expected.
I've tried to write a function that should convert each zero char into a
dot. The following function doesn't work and I don't know why.
On 18.05.18 19:26, James Moe wrote:
On 05/18/2018 09:30 AM, Andreas Schnellbacher wrote:
I've tried to write a function that should convert each zero char into a >>> dot. The following function doesn't work and I don't know why.
It is because you are removing the string terminator.
You need to add a terminator to each string where you replace the
terminator so that downstream string processing works as expected.
Thanks. I see, that makes sense. Sure, that's why in another function double-zero-terminated strings exist.
static PSZ _zerotodot( PSZ pszString)
{
PSZ p = pszString;
if (p != NULL)
{
while ((*p != 0) || (*(p+1) != 0)) // !a || !b == !(a && b)
{
if (*p == 0)
*p = '.';
p++;
}
*p = '.'; // treat the very last "visible" zero terminator
}
return pszString; // you want to return the conv. string, don't you?
}
I still have a problem with the code: The original pszString is converted
to a dot-seprated string, also for the other functions that expect a zero-terminated string. Of course, they produce garbage now.
I still have a problem with the code: The original pszString is converted
to a dot-separated string, also for the other functions that expect a zero-separated string. Of course, they produce garbage now.
Perhaps it would help if you posted the code that fails to do the
delete. It's easy to be off by one if you are not familar with
pointers.
On 18.05.18 21:29, Lars Erdmann wrote:
static PSZ _zerotodot( PSZ pszString)
{
PSZ p = pszString;
if (p != NULL)
{
while ((*p != 0) || (*(p+1) != 0)) // !a || !b == !(a && b)
{
if (*p == 0)
*p = '.';
p++;
}
*p = '.'; // treat the very last "visible" zero terminator
}
return pszString; // you want to return the conv. string, don't you?
}
Thanks Lars, that works.
But I don't understand why pszString has to be returned at the end and not
p. Apparently I don't fully understand pointers. I'm a C beginner.
I still have a problem with the code: The original pszString is converted
to a dot-seprated string, also for the other functions that expect a zero-terminated string. Of course, they produce garbage now.
The original pszString has to be let unchanged. How can I create a copy of
it just for printf output? (I'm not used in when strcpy or strdup should be used. I've tried both and they don't work.)
By the time you're done, p points to the end of the string, pszString
points to the start.
On 19.05.18 18:11, Andreas Schnellbacher wrote:
[...]
In the meantime, I've found the bug in the NEPMD code:
http://trac.netlabs.org/nepmd/ticket/26
http://trac.netlabs.org/nepmd/changeset/3011
Lars' function works, but the original pointer is changed. Therefore
I can't use that pointer for further processing after having used
Lars' function once.
I've moved it in the code until I've found the place were the error
occurs. The bug was that the check
if (!pszEntry)
has to be replaced by
if (!*pszEntry)
to handle empty strings correctly. Sure, you can't understand that,
because the complete code block for reproducing this has 287 lines.
My other problem with creating a copy of a pointer for output
processing (e.g. Lars' function) and using the original pointer
for standard further processing still exists. I'd thought that
strdup should work, but that failed:
static PSZ _zerotodot( PSZ pszString)
{
APIRET rc = NO_ERROR;
PSZ pszCopy = strdup( pszString);
PSZ p = pszCopy;
if (!pszCopy)
{
rc = ERROR_NOT_ENOUGH_MEMORY;
return;
}
if (p != NULL)
{
while ((*p != 0) || (*(p + 1) != 0)) // !a || !b == !(a && b)
{
if (*p == 0)
*p = '.';
p++;
}
*p = '.'; // treat the very last "visible" zero terminator
}
// cleanup
//if (pszCopy) free( pszCopy);
return pszCopy;
}
Any idea what I did wrong?
In the meantime, I've found the bug in the NEPMD code:
http://trac.netlabs.org/nepmd/ticket/26
http://trac.netlabs.org/nepmd/changeset/3011
FWIW, you really should have pointed us explicitly to the nepmd repo
in the first place. It eliminates the need to post code to the thread
or elsewhere. I was a bit slow on the uptake and did not think of
this until late yesterday.
It appears you have a memory leak at:
libreg.c:514
else
// yes: remove this container entry
pszList = NULL;
which will cause the pszList not to be freed.
If I am reading the code right, you are not writing the list
terminator nul to the key value. This probably deserves a comment.
My other problem with creating a copy of a pointer for output
processing (e.g. Lars' function) and using the original pointer
for standard further processing still exists. I'd thought that
strdup should work, but that failed:
static PSZ _zerotodot( PSZ pszString)
{
APIRET rc = NO_ERROR;
PSZ pszCopy = strdup( pszString);
// cleanup
//if (pszCopy) free( pszCopy);
return pszCopy;
}
On 20.05.18 19:06, nospam_2018@efbe.prima.de wrote:
The c stringhandling functions expect a standard c string which is
terminated by the first \0 char. So she strdup will only copy the first
string of your "string1\0string2\0..." example.
And you get a pointer, which has to be freed later on.
[...]
// cleanup
//if (pszCopy) free( pszCopy);
But not in this function, if it used as returnvalue...
That confirms what I thought.
return pszCopy;
}
Thanks, Frank. That was the info I was looking for.
BTW: Do you also have an idea, how to get it copied? (I guess with
memcpy.)
The c stringhandling functions expect a standard c string which is
terminated by the first \0 char. So she strdup will only copy the first string of your "string1\0string2\0..." example.
And you get a pointer, which has to be freed later on.
[...]
// cleanup
//if (pszCopy) free( pszCopy);
But not in this function, if it used as returnvalue...
return pszCopy;
}
BTW: Do you also have an idea, how to get it copied? (I guess with
memcpy.)
C string handling is painful at best. In this case, probably memcpy.
However, how do you identify the end of the string? Presumably, since it's
a concatenation of null-terminated strings the end of all should be identified by two nulls in a row?
In NEPMD, I've a problem with a function that deletes a zero-terminated string from a zero-terminated string list. Therefore I want to make the zero-terminated values at several states visible for printf output.
I've tried to write a function that should convert each zero char into a
dot. The following function doesn't work and I don't know why.
C string handling is painful at best. In this case, probably memcpy.
However, how do you identify the end of the string? Presumably, since it's
a concatenation of null-terminated strings the end of all should be identified by two nulls in a row?
Integer character constants have type int in C. Only the value of
the literal '\0'
If I am reading the code right, you are not writing the list
terminator nul to the key value. This probably deserves a comment.
Steven, I hope I got you right.
Yes, the string list is usually not
double terminated. E.g., when being saved to RegContainer, it's single terminated. Christian had rather commented the parts where he allocates
1 additional byte.
There exist a length parameter: ulDataLen. I haven't reviewed the code
again where the string end is determined by that and where it's handled by two nulls.
Where did the original code come from? It looks similar to some of
the profile code in Christian's WPSTK, but your code probably came
from elsewhere or was heavily adapted.
ulDataLen is set by two different methods and has two slightly
different meanings.
ulDataLen is set via PATHENTRYLEN() which eventually calls PrfQueryProfileSize() so it will be set to the actual size of the key
value in the profile file.
ulDataLen is also calculated using _getEndOfStrList() and will set
ulDataLen to the number of characters needed to hold the strings
following pszNextEntry. The calculated count will include the nul
terminators for each string and the nul terminator that signals the
end of the list of strings.
Thanks, Frank. That was the info I was looking for.
BTW: Do you also have an idea, how to get it copied? (I guess with
memcpy.)
Yes, but to use memcpy, you need the length. This can be calculated by a variation of Lars code: untested
On Mon, 21 May 2018 20:56:57 UTC, nospam_2018@efbe.prima.de wrote:
Hi Frank,
Yes, but to use memcpy, you need the length. This can be calculated by a
variation of Lars code: untested
No need for new code in this case. The library already includes _getEndOfStrList which provides the needed functionality. Currently
it's only used to calculate the length of the tail of the list, but
ulDataLen = _getEndOfStrList( pszList) - pszList + 1;
would provide the count needed by memcpy.
On 22.05.18 17:00, Steven Levine wrote:
ulDataLen = _getEndOfStrList( pszList) - pszList + 1;
Thanks again to both of you.
On Mon, 21 May 2018 20:56:57 UTC, nospam_2018@efbe.prima.de wrote:
Hi Frank,
Yes, but to use memcpy, you need the length. This can be calculated by a
variation of Lars code: untested
No need for new code in this case. The library already includes _getEndOfStrList which provides the needed functionality. Currently
it's only used to calculate the length of the tail of the list, but
ulDataLen = _getEndOfStrList( pszList) - pszList + 1;
would provide the count needed by memcpy.
Steven
On 22.05.18 21:37, Andreas Schnellbacher wrote:
On 22.05.18 17:00, Steven Levine wrote:
ulDataLen = _getEndOfStrList( pszList) - pszList + 1;
Thanks again to both of you.
And for those who are interested: Here's the link to Christian's code: http://svn.netlabs.org/repos/nepmd/trunk/src/gui/common/libreg.c
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 445 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 114:22:45 |
| Calls: | 9,209 |
| Calls today: | 8 |
| Files: | 13,483 |
| Messages: | 6,054,656 |