Re: Some comments about Programming Guidelines White Paper




>    * Do not lock a user in a loop of cascading events because of 
>      errors. The user will consider the tool not only buggy, but also
>      annoying!

I do not think that any programmers actually does this on purpose.
This is more a bug than a design principle.  And it should be dealt
with as a bug, not as a guideline.

It is not a guideline because even if we spell it out and we give the
examples you mention (gmc and the gimp), the situations in which the
bug was triggered were more of a corner-case condition that the
programmer had not expected than a deliberate design.

So, please submit those two suggestions as bug reports to the GNOME
bug tracking system.

>      + Kill your application using the various UNIX signals that are
> 	 available.

Dealing with this is not a priority.  Although it would be nice to
have applications behave in the best way under any signal conditions,
this is equivalent to saying "rm -rf ~/*".

If the user is shooting himself in the foot, that is its problem.

Now, probably signaling an application with a number of possible known
signals that occur during program execution would make more sense.

> * About security:
> 
>   You could suggest some good readings about programming and
>   security, in particular I think one good paper to get the ideas
>   right is "Murphy's law and computer security" by Wietse Venema that
>   you'll find there:
> 
>     http://www.fish.com/security/murphy.html
> 
>   Other papers there (http://www.fish.com/security/) may be of interest.
 
Good thinking.  I will add that.

Best wishes,
Miguel.



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