Check return codes everywhere

Some checks for return codes are missing, as confirmed by numerous gcc warnings. Would you like to add more error handling for return values from functions like the following?

• pthread_create

  main

• HeapAlloc

  MSACM_RegisterDriver - Was the corresponding heap created with the flag "HEAP_GENERATE_EXCEPTIONS"?

• malloc

  HEAP_strdupA

  Open

  EncoderWriteCallback

• realloc

  insert_reg_value

• strdup

  libvlc_vlm_add_broadcast

  Open

  ParseVorbisComments

• read

  FILE_dommap

• fwrite

  CacheSave

• fprintf

  [[/trunk/src/extras/getopt.c@21944#633 (closed)](../tree/master//trunk/src/extras/getopt.c@21944#633 (closed)) _getopt_internal]

• asprintf

  vout_Snapshot

changed the description

changed the description

added Type::task label

changed milestone to %Bugs paradize

added Component::Bindings: LibVLC (native API) label

assigned to @ivoire

I closed the ticket as I think it is not useful. Of course, error code should be checked but I really doubt that the ticket is useful in itself.

added Status::invalid label

closed

Replying to [comment:6 fenrir]:

I find your opinion about the relevance of this issue strange.

I suggest to avoid unchecked function calls. Would you like to detect every error situation as early as possible?

removed Status::invalid label

reopened

What fenrir says is that the ticket is useless.

OF COURSE, functions calls should be checked. A patch would be useful for that, a ticket, not.

added Status::invalid label

closed

We have enough opened tickets to manage, to not add more work to it.

Would you like to reduce the manual efforts for error code checking?

How do you think about to encapsulate such issues as aspects?

It must be done manually after warnings checks.

Replying to [comment:11 jb]:

There are tools like "Coccinelle" and "AspectC++" which can eventually help to fix open issues. I am unsure if you would like to accept patches from such a direction.

Personally I never used aspects but I think it would be interesting.

Do you mean you would contribute coccinelle-like semantic patches if we applied them?

We don't have a lot of C++ modules (i.e. mostly those who use C++ libraries) although it seems to be a growing trend these days.

Replying to [comment:13 funman]:

I propose to formulate patches in the syntax from one of the mentioned software developments tools.