Ch40zzC0d3r thanks for your reply, i noticed it after a fairy long time

I will try this approach, i hope it fits to my requirements.

Edit: At first run, the line beginning with typedef throws a syntax error message.

maybe you have to include windows.h?

As I said in the PM, lite-c doesnt need typedefs.
Just declaire the function as usual.

Dear Mr. jcl!
You wrote:
In my application showing a wrong image wouldn't mean an unrecoverable error.
In this case the app throws a message about the error and everything goes on, and doesn't want to show that image, so there is no problem.
Why is this so hard to the 3D GS engine? This situation can be handle without any problem.
I need only a short error handling code in lite-c. If it is a secret, you can send it me in a pm, or if you want i can give you my e-mail address.
Please, Mr. jcl share with me, how should process such errors.
Thanks in advance.

Hmm, I hoped that problem had been explained, but apparently not.

In a programming language, a function that gets wrong data normally returns with an error code. That just means that the function did not work properly. What you do in that case is completely up to you - you can show a "wrong image", whatever that means.

But when you get a crash, something essential went wrong. An example is loading a file with wrong content that overwrites internal data areas. The function can then not continue and often not even return. It must produce an error message that tells the user that the program crashed. This can not be "masked out" and replaced by a "wrong image", because it's quite possible that your wrong image code will never be reached.

I hope this helps understanding the difference between a recoverable and a not recoverable error.

First of all, thanks for your efforts to deal with this problem and with me.
I try to explain myself in other way.
Let's see an imaginery code:
What wrong can be happen with me, if i handle this way the error?
There is no crash, no end of world or other bad situation...
Moreover, i can not believe a well written code can overwrite internal data area like the stack. Tell me, other applications why does not crash when the user try to open a wrong image? Like Photoshop, Paint, miscellanous image viewers, browsers and so on...

This is called ExceptionHandling, and completely missing in LiteC. Real ExceptionHandling allows you to even handle Doom-Errors in a Userfriendly way, and sometimes even allows you to recover.

A fatal error is not always a crash.

Aku Aku: Certainly they do - especially Photoshop. Depending on where an image file is damaged, you can get the same error message, followed by a program termination.

What we can do for you depends on the file format. If it is loaded in an external module such as DirectX and causes that module to crash, the engine will definitely produce an error message. We can't change that for the mentioned good reasons.

If however it is loaded directly by the engine, like PCX and TGA, additional format checks would theoretically prevent many possible crashes. But how often do you have images in damaged format? Would it not be a lot easier when you just check before loading if the file exists or not - which is probably the most frequent error reason?

Thanks for your reply.
OK, i accept in these situations the applications abort their runs.

I would happily code an image checker subroutine. But i don't know the engine inside and its source, its code and data structure, its algorithms.
And i need to do exactly the same that the engine does, and how it does. Moreover, i need this in lite-c.
It would be nice, if you provide to me the lite-c source code, how the engine checks an image format, and how decides it is good or bad.
I would appreciate that, and certainly the community of this forum would be also grateful.
Here in this topic or even in the next AUM.
Thanks in advance.

It's hardly going to use Lite-C code, and there is more than one method that checks wether an image is "good" or "bad". It actually is quite easy when you make the assumption that, as long as the image is valid and its format is supported, the engine is going to accept it. For png, use libpng to open the image and do some sanity check on it, for bmp you can write a parser on your own since it's pretty much just a flat binary (Wikipedia has the infos on the file format), for tga there is libtga, jpeg is covered via libjpeg and for pcx, dunno, but you can probably google something.

Though, since you are already parsing the images yourself, it would probably make more sense to also load the bitmap data yourself and pass it to the engine, or at least read the whole image into a buffer and add it via add_buffer(), as to avoid redundant I/O operations (opening and reading images is already expensive enough, no need to do it twice or more times).