On Mon 25-07-11 14:52:33, Nikiforov Alex wrote:
> On 07/25/2011 12:31 PM, Michal Hocko wrote:
> > [Please use reply to all]
> >
> > On Mon 25-07-11 07:43:07, Nikiforov Alex wrote:
> >> On 07/22/2011 06:11 PM, Michal Hocko wrote:
> >>> On Fri 22-07-11 08:53:53, Nikiforov Alex wrote:
> >>> Why should we do snprintf if we know that the given parameter was not a
> >>> number or it contains some garbage.
> >> I really dont like exception style coding in plain C. It's hard to read
> >> as well as hard to debug when you add some traces (this is IMHO too). We
> >> can add goto, but it's really ugly style here not so much work happen to
> >> add goto, snprint() is reenterant in this case it's fast. Dont see any
> >> point to add goto here.
> >
> > You can also create a monster error condition which would be even
> > more subtly. The point is, why do you want to burn CPU cycles if you
> > know that what you have in pid is not what you want to turn into a
> > number. But hey, I am not a maintainer or anybody who can tell that this
> > is unacceptable.
> 
> I agree with you in the point that when we have huge amount of the 
> checking we should (or may be must) do it in the exception way. But in 
> this particular case, sorry Michal but I dont agree with you.

You are, of course, free to disagree. As I already written, I am not a
maintainer so my opinion can only help/distract you with/from the right
way to do it.

> We have pretty simple operation and it's not the price for exception
> with goto here, sorry but it's my point. I agree with your point
> about checking also on server side it was reasonable, but this dont
> take any speedup, just obfuscate the code with goto[some amount with
> code]label:.

You do not have to use goto at all - that was just an example. You can
of course do also (!*endptr && snprintf()) - not that nice because you
repeat a condition so you can end up in a mess if this ever get more
complicated.
The point is _never_ call any code that is pointless to execute because
assumptions that it expects are not meet. In this particular case, do
not call snprintf if the value you are about to convert is meaningless.
You have to be defensive when you are processing inputs from untrusted
sources (here the input read from socket).

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel

Reply via email to