Re: Check return codes everywhere

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Sincerly,

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C

Attachment: signature.asc
Description: Digital signature

_______________________________________________
gpm mailing list
gpm@xxxxxxxxxxxxxx
http://lists.linux.it/listinfo/gpm

[Index of Archives]     [Kernel Development]     [Red Hat Install]     [Red Hat Watch]     [Red Hat Development]     [Gimp]     [Yosemite News]