The docs never said not to pass 0,0 to create_bitmap, so your point is mutt.

They also don't say not to pass a casted BITMAP pointer to play_sample. So the docs not saying something is not enough to say that "your point is mutt". At least is isn't based on my guess at what you mean by that, i.e. that mutt means void.

No one with a brain would do that, but there are zero size arrays so who's to say you can't make a zero size bitmap.
please use your brain before making counter arguments.</annoyed>

I'll use my brain when you start saying what you mean. Your sentence was "The docs never said not to pass 0,0 to create_bitmap, so your point is mutt." which implies to me merely that points are 'mutt' if they rely on people assuming things that aren't in the docs. I suggest you try a sentence such as "This isn't obviously going to cause a problem and the docs never said not to pass 0,0 to create_bitmap, so your point is void." should you ever want to make the same point again.

That's to long a stentes for me. I like to be short and to the point, witch sometime makes me sound rude. Ok. If your going to be overly picky end it with </jk>, or some thing like that.

Couldn't you pass an error message to an internal string, set a flag, return without crashing and then in a seperate thread check for an error in the background and print out the full error details?

Or call a function pointer (if not NULL) from within each function if an error occured and passing it the error text. That would let people use custom error reporting functions..

I think it depends on the optimization settings and the compiler. I rememberfor one game I was making, DJGPP would print "(null)", but under Linux, with a newer GCC, it would crash.

given create_bitmap() is not speed critical, is there any harm in adding the check.
i also like the point ReyBrujo made, that its often a noobs 1st choice of game lib, so lets make it as helpful as possible.

can we set a errno number for this condition, so the user after receiving a NULL ptr can check it to find out why.

Just a quick round of answers before I roll into bed. These are my personal views after skimming through the thread with a throbbing headache and a sore throat so I apologise beforehand if I insult anyone.

The docs clearly say that you cannot create a 0x0 size bitmap. If you try to do so anyway, the consequences are for you. Perhaps it can be argued that destroy_bitmap() should not crash or create_bitmap() should return NULL instead, but since the user code is in error in this case I personally don't think this is proper behavior for the library. Changing this in the way suggested will make code run normally (without errors) in release mode and it will cause a crash in debug mode. This is not acceptable.

Allegro's policy is to do pedantic sanity checks only in debug mode and at least for 4.2, this is not going to change. How failures and problems should be dealt with after 4.2 is a different discussion.

No, passing NULL to a %s format specifier in printf() is not ok. If the result is the insertion of the string (null) this is non-standard behavior (granted, it's non-standard behavior used by many compilers, but it's still non-standard). We've had a few patches to Allegro that solved crashes because the library assumed it did.

kittycats suggestion, of leaving the asserts in but including the check after the asserts, would allow debug & release modes to act consistantly, whilst offering warnings to users in debug mode via the asserts.

Should all non-speed critical functions check input parameters for sanity ?

[edit]
create_bitmap() docs say:
"Return value: Returns a pointer to the created bitmap, or NULL if the bitmap could not be created."

to me the "or" word implies the 1st half of the sentence is the opposite to the end, the end being NULL if not created, therefore the start of the sentence says non-NULL if created. So if a bitmap is created successfully (non-NULL ptr), then it should be able to feed that ptr to destroy_bitmap() without a hard crash.

BTW

Returning a NULL bitmap is considered an error (it's not wanted behavior).. means something went wrong and the bitmap couldn't be made. I can't think of a situation where a returned NULL bitmap doesn't indicate a problem. However, by returning NULL in release, it allows the program to handle it more gracefully, while in debug mode the ASSERT's would throw the problem to the debugger.

EDIT:

create_bitmap doesn't crash. It crashes when you try to call destroy_bitmap on a 0-sized bitmap. And no one's saying 0x0 bitmaps should be allowed.. we're just determining what the best method of dealing with it would be (return an error with a NULL bitmap so the program can handle the problem, or let it create an invalid bitmap that will crash the program later).

Which is why we're bringing it up, since someone else found it.

What should be checked by the user, and what should be checked by the lib? In non-speed-critical functions, such as this, it should be safe to assume the lib will make sure it won't cause a situation to allow itself to crash later.

When your projects get larger and larger, it becomes increasingly harder to keep track of everything. Situations that couldn't happen before could happen now, but you wouldn't realize it until it's too late. For non-speed critical functions, it'd be best to let the lib check and save on having all of its users program the exact same safety checks (or not, and risk questions of why the program crashes, and time wasting hunting uncaught problems).

Not in situations where I can't conceive B being 0. And if it is, it'll crash, I'll debug, and catch the problem. Something like this would be easy since it crashes right where the problem is. But with a 0-sized bitmap, you may not get a crash until the program closes, even if the problem is when the program begins.

it is speed critical if you do this:

while(do_draw){
line(...)
}

an error check will slow the draw loop.

create_bitmap is so slow that adding a check there is depreciable.