Sorry for being busy today Addressing your first post's points:
0.1 and .1... I thought that it was working just fine :-X Guess I need to look it over
Yeah, that function is incomplete. You read the commit message "Pushing all changes to svn so I don't lose them", since I usually note if things get fixed, or is unstable, etc.. These commits were done even though I wasn't finished and stopped mid-command due to that netbook dieing and is scheduled for a new os.
Yup, those functions aren't there. However, gCAS2 shouldn't crash on them.
Hmm... I need to rethink adding official prizm support. I need to first figure out how to get 3 targets to work with my Makefiles
The mallocs failing would be very useful for GlassOS, maybe not useful on the prizm, and not an issue on desktops I will 3+-2 is valid, treated as (3)+(-2), much trail and error coding went into that. 3.3.3 ... uh, silly gCAS2 If it tells you 3.3 as the result, then (1) my parser for getting the wrong length and (2) atof for filtering out invalid characters, stopping at the second '.'.
Second post (reading in the order I type):
Sorry, I tried to track down all hard coded values, but definately missed some. I had them in when I was mearly testing out functions for the first time.
I believe it does free them on an error, not sure.
For that new function, I like your return method
Ok, so here comes my problem with the C language.... VS doesn't simply refer to the fact that a node has many children, it also points out that the malloc is of a variable size. C structs, as far as I tried, cannot be made to recognize the last variable as an array of undefined size. So, the last variable is technically a cas_node array (from the last variable until the end of the malloc'd struct) of pointers. I did it awkwardly to avoid different compilers from yelling at me.
So, your gcas_tree_copy function is incorrect as the nodes variable is not a pointer to a malloc'd buffer, it is an array itself of length 'size'. If you look at my line to create a cas_node_vs:
Code:
You can see that the cas_node_vs has on cas_node* as the last variable and is included in sizeof(cas_node_vs). I do size-1 to account for that. the *sizeof(cas_node) is there since the malloc holds the array.
I hope that clears up the VS nodes. Fire away more questions if you need to, as my phone line came back up today
Warning! I have committed revision 78 that fixes the building of gCAS, please update to that version! The problem with the arbitrary functions has been fixed already and was finally committed. Building also works. This revision does not have bug fixes mentioned in above in the post.
0.1 and .1... I thought that it was working just fine :-X Guess I need to look it over
Yeah, that function is incomplete. You read the commit message "Pushing all changes to svn so I don't lose them", since I usually note if things get fixed, or is unstable, etc.. These commits were done even though I wasn't finished and stopped mid-command due to that netbook dieing and is scheduled for a new os.
Yup, those functions aren't there. However, gCAS2 shouldn't crash on them.
Hmm... I need to rethink adding official prizm support. I need to first figure out how to get 3 targets to work with my Makefiles
The mallocs failing would be very useful for GlassOS, maybe not useful on the prizm, and not an issue on desktops I will 3+-2 is valid, treated as (3)+(-2), much trail and error coding went into that. 3.3.3 ... uh, silly gCAS2 If it tells you 3.3 as the result, then (1) my parser for getting the wrong length and (2) atof for filtering out invalid characters, stopping at the second '.'.
Second post (reading in the order I type):
Sorry, I tried to track down all hard coded values, but definately missed some. I had them in when I was mearly testing out functions for the first time.
I believe it does free them on an error, not sure.
For that new function, I like your return method
Ok, so here comes my problem with the C language.... VS doesn't simply refer to the fact that a node has many children, it also points out that the malloc is of a variable size. C structs, as far as I tried, cannot be made to recognize the last variable as an array of undefined size. So, the last variable is technically a cas_node array (from the last variable until the end of the malloc'd struct) of pointers. I did it awkwardly to avoid different compilers from yelling at me.
So, your gcas_tree_copy function is incorrect as the nodes variable is not a pointer to a malloc'd buffer, it is an array itself of length 'size'. If you look at my line to create a cas_node_vs:
Code:
(cas_node_vs*)malloc(sizeof(cas_node_vs)+(size-1)*(sizeof(cas_node*)))
I hope that clears up the VS nodes. Fire away more questions if you need to, as my phone line came back up today
Warning! I have committed revision 78 that fixes the building of gCAS, please update to that version! The problem with the arbitrary functions has been fixed already and was finally committed. Building also works. This revision does not have bug fixes mentioned in above in the post.