AllocVecTags

[abalaban]

@Tony

The problem here is that Josh sent incompatible parameters to AllocVecTags() ie. AVT_TYPE with MEMF_ANY. He's already checking for return but in this case AllocVecTags() allocated something that is not usable, instead it would have been better if AllocVecTags() returned NULL.

[Thomas Frieden]

I can't but rephrase that i am rather disappointed that "the SDK does not provide more in detecting wong input to functions with a limited number of acceptable parameter values" If the easiest solution to this means that such library functions should be rewritten to fail more gracefully and provide help info, i am all for it.
If all this is unrealistic, so be it.

When you write code, it is your responsibility as a developer to at least check the documentation of functions that you are using and understanding what they do. In this case, changing from AllocVec to AllocVecTags, you simply did not check the documentation of the function, otherwise, you would have known that the value was illegal.

If every function would validate it's input completely, it would be far too slow. Therefore, the system relies on some validation done by the developer. It is not feasible to have a function always validate it's whole input since of all the millions of cases the function is called, the input is always right except for one or two cases.

Finally, if you are interested in fixing this problem (yes, it MIGHT be a bug, I don't know), I would appreciate if you could give constructive feedback. For example, the "unhelpful crash" is actually even more unhelpful if you keep the details to yourself. If you would share the crash, I could actually check if there IS a problem with the function and fix it.

[Hans-Joerg Frieden]

I am rather disappointed thet the compiler does not give any warning, error or undefined reference in this case.

That is impossible because tag IDs and tag data are all uint32 types. There are no types for the compiler to check.

Not that there was any way to check anyway, even on the old system if you wrote "AllocVec(size, 42)", you'd get everything but the answer to the universal question. It's a general problem with tag items, but even with normal parameters you would run into this problem.

As everybody pointed out already, it pays to check the documentation

[abalaban]

@Hans-Joerg & Thomas

I agree that it's developer responsibility to read, understand and conform to the API documentation.
But on the other hand it would make sense if AllocVecTags() doesn't allow impossible combinations, returning NULL instead of an allocated object that is known to be crashing the next instruction.
I didn't tried myself the code above but my understanding of Josh problem is that AllocVecTags() was returning a value different from NULL but unusable, in such case then it's a problem in AllocVecTags(), if instead it's AllocVecTags() that is crashing because the calling programmer didn't conform to the API then it's mixed because it's the calling programmer's fault (if you'd asked my I would also have deemed a part of the responsibility on AllectVecTags() for not being error tolerant proof, but it's only IMHO .

[Thomas Frieden]

But on the other hand it would make sense if AllocVecTags() doesn't allow impossible combinations, returning NULL instead of an allocated object that is known to be crashing the next instruction.

See my post again. As I said, it shouldn't crash, so I would like to see the crash it produces, or maybe a description of what is wrong. For example, no one mentioned that it will return a value that is nonsense.

In general, "It doesn't work" or "it crashes" is bound to be ignored. A description of an error is something else, and can be fixed.

I still stand by my original assessment, though: It is impossible and impractical for functions to fully validate their input for correctness.

[JosDuchIt]

In general, "It doesn't work" or "it crashes" is bound to be ignored. A description of an error is something else, and can be fixed.

I was never implying that the function was buggy. Being accustomed to more userfriendly languages than C and ignoring what the compiler checks (types) and what the functions can or cannot check taking speed into account, i just made an uniformed statement.

I cannot report more about the crash than that it did freeze everything, no debugging output whatsoever. To my knowledge ANY_MEM was not defined in the system, and indeed i should have checked again (i really did but then left an uncorrected line and took ut ip a week later.
Checking the function again in the context of a large source file and seeing the same crash again will not give any more info i think. Or can it ? I am not able to give more info anyway right now

[ssolie]

I cannot report more about the crash than that it did freeze everything, no debugging output whatsoever...

It is a good idea to have the serial port connected via null modem cable to another computer to capture any output. It can also help to use the so-called debug kernel which is named kernel.debug. Finally, you can adjust the amount of debug output using the kdebug command.

It is easy to lose a week of time when the system "freezes" but that is actually very rare. There is almost always something output via the serial port which can help save you that week of time.

It is my hope these types of tips will be made available on the official AmigaOS developer wiki which is next on my list of projects.

In any case, without such debug output Thomas can do nothing for you. What may help is if you provided the smallest compilable code fragment you can which reproduces the issue. That way others can at least try the test with a properly setup serial port output and maybe provide Thomas with something to work from.