[gpm] Check return codes everywhere

Nico Schottelius nico-gpm@schottelius.org
Tue Feb 3 12:10:02 CET 2009

Hey Markus,

Markus Elfring [Mon, Jan 05, 2009 at 09:40:27PM +0100]:
> > Maybe adding errno to gpm_report() as an additional argument
> > and strerror() it, if it's non-zero could do the job.
> Would you like to introduce this little improvement for better error explanations?

As usual, I'm busy, but I'm open for patches against gpm-2-dev.

> > I must confess that I would like to have gpm cleaned up much more,
> > before we add more dependencies on other projects.
> I am curious which refactorings will be acceptable for the current source files
> to complete the error handling.

Just give it a try and ask when you're unsure.

> > I personally see no advantage using try{} catch(),
> (C++) exceptions provide a means to support more powerful error reporting.
> Will all function implementations stick to a traditional C coding style forever?

Jep, it will stay C.

> > the ACC idea looks somehow nice, maybe something for the future.
> Are there any chances to integrate a tool like "AspectC++" into the software
> build process?
> http://aspectc.org/

I don't think this will happen soon. The big problem is that more development
takes place in other places (like linux-input) than in gpm.

> How do you think about to write filters for specific function interfaces?

I am not sure what you mean by that.



Think about Free and Open Source Software (FOSS).

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.linux.it/pipermail/gpm/attachments/20090203/a95f8541/attachment.pgp>

More information about the gpm mailing list