Whoops. I might add that, if instead of closing the '0'ed socket, I let it try to recieve a message, I get the "Socket operation on non Socket" error, which I suppose means 0 is reserved for something else.
Actually, it just wasn't seeing the VolumeGroups no way no how, which meant that unless we dumped out the raw data onto another drive and sorted it out, the partition was basically trashed. We decided it wasn't worth it. It seems like a really weird issue, but LVM basically messed up bad.
What...
None of that really help. The thing is, Redhat's hardware browser shows that there's an LVM on the partition, but LVM itself doesn't recognize it. I set LVM to level 3 verbosity, and it says that sdb3 has no label, so... I don't know if there's someway I can make LVM point to the data.
Somebody at at the office needs us to recover information of of a linux HD that won't boot, so we plugged it into our Redhat machine, and the partitions on it are as follows:
/dev/sdb1 - boot
/dev/sdb2 - swap
/dev/sdb3 - LVM
Unfortunately, since all the infomation about the volume groups in...
...of whack. Could it be an environment issue? I can't seem to figure this out, so any help would be appreciated.
The source code up to that point is mostly just the assignment of some ints and some char*s and the calling of main(), but I'll post the source if needed.
Thanks for your time
-Guest42
Well, I just fixed the program. I found out I can just say:
realloc(v->go, (v->capacity * sizeof(struct game_object*)));
Instead I have to do this:
v->go = realloc(v->go, (v->capacity * sizeof(struct game_object*)));
Or else v->go might not get moved to the correct spot.
Also, I had to...
Actually, the line: v->go = (struct game_object**)malloc(v->capacity * sizeof(struct game_object*));
Isn't determined by the length variable (which is the current number of elements stored), but by capacity, which isn't zero. Perhaps my naming system could be better, but this line is necessary...
Right. Not a real big concern, just wanted to make sure I understood how it works. There's still the problem that, in the program, v->go[0]->x returns some address rather than the value of x, where as the rest of v->go[n]->x return the value of x. I can't figure out what's up with that....
So using realloc(), this seems to do the same thing that the made-up-out-of-my-head struct does, in a much less complicated way:
http://cyberworld.kicks-ass.net/comic/VectorRealloc.c
The only problem is that trying to access v->go[0]->x brings up a memory address rather than the value of x...
I suppose I ought to take a look at a C++ vector then. The reason that I didn't think about realloc() was because I didn't know it existed until this thread o.O I also didn't realize you could implement void like that, though I realized there must be some way to do in C what you can do with...
Actually, scratch that, as making a copy of the pointer wouldn't make a difference, since I'm going to end up with the same space used, ultimately pointing to the same spot. Duh.
Anyway, you say access will be exponentially slower? If you have a lot of little nodes, this would certainly be...
Well, you probably know better than I, but I think that sending it through like that makes a copy of the the argument, rather than just dereferencing your pointer, which is what I need to do. Like, if you want to dereference int n, you need *int, and if you want to dereference int *n, you need **int
Alright. As sort of an experiment I wanted to see if I could make a Vector (expandable array) in C, kinda like the Vector class in Java, only this one holds a specific type of structure. It appears to be fairly successful, although it is very simple at this point. Anyway, I was hoping someone...
Quick syntax question
If I have some field **go
and I say *go = malloc(sizeof(whatever))
If go is a field in struct v, how would I achieve the same thing? For example, "v->go = malloc" would be the same thing as go = malloc, but I need *go = malloc.
I understand what you're saying cpjust. Makes perfect sense when I think about how strtok works, but I didn't know the reason for it. And thanks for the info, ArkM. For my purposes, I don't think strtok will be dangerous, but I'll make sure to keep this in mind.
Anyway, I want to thank everyone...
Still, it bothers me, looking back, that strtok() is unsafe for threading. Not to drag this forum thread on longer than it needs, but could you explain a little to me about what the issues with strtok() are that make it unsafe for threading? What are the potential negative effects? I don't mean...
...more clever about how I write my programs. But at least for now I can look at it and learn something from it.
Would it be reasonable to allocate **ret inside of the function, rather than allocating u before hand? I'm guessing that there are useful functions in the string.h lib that would...
Well, the output seems to be better, and yet str still gets cut down, and I have no idea why. The reason this bothers me is that I am just trying to get the hang of pointers, but I don't really undersstand why this is happening. Coming over from Java where I don't have to worry about this stuff...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.