[MiNT] XaAES crash errors

[Paul Wratt <paul.wratt@gmail.com>]

First, thank you ALL for your replys

2009/12/6 Vincent Rivière <vincent.riviere@freesbee.fr>:
> Paul Wratt wrote:
>>
>> The question: how do I pass "char *line" through to an intermediate
>> function that can then pass "&line" correctly. Would passing "*line"
>> be enough..
>
> Things are not so simple, that *, ** and & are not here by chance.
> We can't answer this question without knowing the context. It seems you want
> to split a function into 2 functions, which is probably good.
>
> You should post here the relevant elements of the function in question and
> we will answer on a concrete example.
>
Thanks, I will be "explicit" with future posts

> But we must keep in mind that writing C programs is complicated.
> With a basic knowledge of any programming language, it is possible to read
> and understand most C code (except some language elements which are tricky).
>
yes, this is my understanding also, I must experience, or be told
about, the tricky bits, "searching" for them turns up nothing atm.

> Writing C code is another story. It is usually quite difficult for C
> beginners to manage to compile a program. And when it finally compiles, they
> say "Hoorah !" but most of the time the program is full of bugs, and it
> crashes at runtime or does a wrong thing. The C language is even more evil:
> sometimes it seems the program does the right thing, but actually it writes
> to illegal memory, so it works by chance and it is trashing something else
> which will crash later in a incomprehensible way...
>
This is also my understanding, hence coding many languages for 20+
years, I skip straight to "the good stuff", as long as it compiles,
and the base code is "stable"

> I just want to say that refactoring a complex code as you are doing require
> solid C skills, there are good chances that you will break something away
> without seeing the effects. Then it will be a headache to find bugs...
>
What I know of code in general, and I include differing coding styles
in that, XaAES is for the most part "fairly clean" and well written.
The are area, as noted by others also, that are "not so great", which
just means a lot more back and forth cross-referencing and searching
in order to make sure any "changes" do not have "hidden"
repercussions, or "brake other things". Refactoring in general is not
differcult (for me) even without experience in the language, as long
as the code is "well layed out", which for the most part it is, so
most changes are just "cut and past" with the odd bit of #if and
#define to get it working again.

> So you should really begin by improving your C knowledge, as it has already
> been told here.
> Well, this is just an advice.
>
> Vincent Rivière
>
I think the one this "doing theme related changes" qualifies as
"improving your C knowledge". The bit that is missing from every
bodies comments "as it has already been told here", is "XaAES is out
of your league". I dont believe it is, I consider kernal at the
beginning of that boundary, not interface related kernal modules.

Everyone, Please dont take the above paragraph the wrong way, I do
understand that it means a "filling some very big shoes", and is a
learning curve that most would not climb by choice, but I am up to the
job. By christmas you will have a more stable and prettier version of
XaAES in Beta status (including Helmuts work that is, and any other
patches floating around). The for runner to a v1 Release for BOTH 1.16
and 1.17 which is still light and compatible with current configs.

At some point after that things will branch, or a "rewrite" will be
forth coming, but that is for later, and may or may not be open for
discussion..

To drive home what I do understand, can I as why a kernel module can
"fail to exit". It is one of (possibly) many all designed to work
together, therefore one can not afford to lock the system if it does
fail. Is it possible that I caused an underly bug to be exposed,
resulting in the output of this threads first post. Is there any way
to test this. Is anyone available to test it. ATM it is beyond me
(soon maybe)

Again thanks to everyone for there advice, in future I will be more
explicit in my questions, with supplied code. I will also seek to NOT
make advanced changes with out doing incremental tests.

BTW, what I think "broke" the km, was reverted, and I can say that it
was unrelated to anything I have posted about or ask (weird) questions
about. I added "SKIN_DIR" to path loading, which also required
"fixing" XA_XTOBJ.RSC loading, and I used XAAESWDG.RSC loading as a
basis for that. There are however some underly differences in how
those two resources are handled, which was the part that broke.

ALSO, the question that was related to *, **, an &, my current
solution is to NOT use intermediate functions. This just meeans "code
double ups" for certain functions which was my greater concern (other
people reading the code, and extra binary space taken), but I can look
at that later on, when I do "have more experience". It is possible
that what I have will work, but I was concerned that it may have
contributed to the "inital crash".

ANYWAYs, anyone who does not know yes, a new version of MyAES should
be out "just now" (soon), and I have got "the 1st of many" gradient
files completed for compile inclusion. I will release a download and
patches of these sources when I have completed another 5 of them.
screen shots are here (at the top):
http://paulwratt.110mb.com/afros/skins/xaaes/

Anyone with XaAES and 1.16 can get an "improved" version ("make all"
binaries with "strip -s") for all targets (top link).
http://paulwratt.110mb.com/afros/skins/

Thanks again for peoples time and wealth of knowledge (and previous
years of hard work)

Paul
Thanks to Henk for off-topic opportunity :)