|
I am really puzzled by how difficult it seem to be to explain how the value of that .directory was initialized. Where its value came from. How it was created.
Obviously, whatever created the value did not follow the C convention of terminating it with a nul - most likely because it doesn't have a C origin. Fair enough. But why is it so difficult to show how the .directory value was obtained?
As it now stands, it is like complaining "This variable should have av value between 0 and 100, but it is above 100. Why???" If you can't figure that out yourself, you must reveal how you calculate it, you cannot simply tell us how you use it, after it has gotten that out-of-range value-
Your directory string is another out-of-range value. How you use it, after it got this illegal value is of no interest. The important thing is how it got that value, not how you later use it. Like if you ask "Why does my value exceed 100?" Noone can tell unless you tell how you got or calculated that value. String values are no different: If they have an illegal value, such as not being nul-terminated in contexts where that is expected, the problem is in the source, not in the use of the value.
If it is as difficult as it seems to trace the source, identify where that directory sting came from, then you should not expect others to be able to help you. "I have an illegal value, but I can't tell where it came from - why is it not legal?" - noone can give you a reasonable answer to that.
So come on, tell us how the .directory value was obtained/created! Until you do that, you cannot expect any useful help from other forum members
|
|
|
|
|
I think you may be banging your head against a brick wall. I have tried this approach repeatedly and got nowhere. But well done for trying.
|
|
|
|
|
I'll try myself the piece of code that I am putting here, by now I have taken the code from real project. I come back soon. I only need to move those structures in a test app and make it run.
modified 1-May-20 11:17am.
|
|
|
|
|
Here is what I've discovered by now:
dir_data_t directory_data;
strncpy(directory_data.current_directory, "/", sizeof(directory_data.current_directory));
directory_data is ok by now.
struct list_head* filewalker = NULL;
file_info_t dirlist;
logdir(&directory_data, &dirlist);
INIT_LIST_HEAD(&dirlist.list);
const file_info_t* current_file = NULL;
list_for_each(filewalker, &dirlist.list)
{
current_file = list_entry_const(filewalker, const file_info_t, list);
TRACE(_T("current_file->name %s\n"), current_file->name); }
after that,
strcat(directory_data.current_directory, current_file->name);
is not ok, of course. INIT_LIST_HEAD, list_for_each and list_entry_const are Linux functions. logdir functions I could not reproduced in a test app or write here because has many dependencies ... and to be everything more complicated, all this code is written in a recursive function .... is quite difficult to reproduced this situation in a test app ... I am trying to explore logdir function to see what I find there ...
|
|
|
|
|
That looks quite likely that some entries in your list are either corrupt, or have not been set to a valid entry.
|
|
|
|
|
Just to clarify over on pointer/array as argument
One way is to pass the array as pointer
int Function( int * arrayargument)
{
for(int i =0; i < 10; i++)
{
arrayargument[i] = 1;
}
}
int AnArray[10];
Function(AnArray);
Function(&AnArray[0]);
could same result be achieved by calling it case2 mode?
|
|
|
|
|
Yes, in case 1 the compiler assumes the name of the array actually means a pointer to the first element. In case 2 you have specifically requested "pass the address of the first element of the array".
|
|
|
|
|
Thanks
When you can do the same thing in several ways something is not right 
|
|
|
|
|
fearless_ wrote: When you can do the same thing in several ways something is not right
I can only imagine the following program will blow your mind:
#include <stdio.h>
int main()
{
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7};
int i1 = a[2];
int i2 = 2[a];
printf("i1 = %d i2 = %d\n", i1, i2);
return 0;
}
Keep Calm and Carry On
|
|
|
|
|
I would also pass the size of the array to the function instead of hard-coding it at 10:
int Function(int* arrayargument, size_t size)
|
|
|
|
|
I was trying to keep the example as simple as possible. But since we`re here, what`s size_t? It`s the second time I see someone using it, is it an actual variable or just a custom?
modified 28-Apr-20 11:04am.
|
|
|
|
|
size_t is just a type. Like int, long, and so on
|
|
|
|
|
Thanks Victor
you mean a built-in type in a c++ compiler? what makes it particular, with float the compiler will let you use the comma, char is a like a tiny int, what makes size_t special?
modified 28-Apr-20 16:22pm.
|
|
|
|
|
|
oh so it`s a class object from a library not a built in type.
modified 29-Apr-20 16:34pm.
|
|
|
|
|
|
Are you bored? don`t be, I`m learning
|
|
|
|
|
Don't worry! Just learn!
And sorry if I wrote something wrong here!
|
|
|
|
|
|
The wininet library in Windows contains APIs for "cracking" and parsing network URIs into their component parts.
Are you aware of any facility in Windows that performs this function for command lines? (Something that I can call from an application, not the parsing that is done when my application is launched.)
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Are you talking about the contents of argc and argv?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Yes, and the executable name.
I imagine each argument separated into an array, and the executable name separated.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote:
I imagine each argument separated into an array, and the executable name separated.
All of that is contained in the argv vector. For the executable name, look at the 0th item.
For WinMain(), you may have to refer to __argc and __argv instead.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Thank you David.
I didn't make it clear enough at first. I meant that I want my application to be able to parse the command line of a separate process.
You know how some registry keys have command lines in them? I was wondering if there is something built into Windows that can make it easy to parse them.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Ahh, that's a horse of a different color.
If you tried separating the tokens using a space as the delimiter, an issue that I see is that the path\executable name can itself contain a space. This is usually resolved by surrounding that token with quotes. So as you are parsing the whole string, you'd need to keep track of whether you were in a quote or not. If so, then spaces do not count.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
