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

Re: [Xen-devel] [PATCH v2 5/5] libxl, hvmloader: Don't relocate memory for MMIO hole



On 20/06/13 11:37, Ian Jackson wrote:
George Dunlap writes ("Re: [Xen-devel] [PATCH v2 5/5] libxl, hvmloader: Don't 
relocate memory for MMIO hole"):
It may be pointless from a functionality perspective, but it's also
harmless.  It won't add a single byte to the compiled code, but the 6
characters will remind a developer reading the source that there is a
cast being done here, just in case it should ever become important.  Not
super important, but I'd rather leave it in.
IMO this is a terrible reason for a cast.  Casts are dangerous things
to have in code - they can override the compiler's normal
typechecking.  They should be used only when actually necessary, and
code should normally be constructed so that they aren't.

Doing this would effectively hide the "default" value.  This is bad
because 1) it's not clear what the default is to someone just scanning
the code, 2) it's hard to change.  (Consider how you'd modify the above
statement if you wanted to default to 0 instead.)
I agree with this complaint.

Sorry, which complaint? Jan's complaint that we have an "unnecessary" if() statment, or my complaint that not having an if() statement is confusing? (That's the topic of this paragraph.)

Or did you mean the complaint above, i.e., casting the result of strtoll()?

I don't care terribly much about the casting; I'll change it rather than argue about it. :-)

Does anyone has any opinions on getting rid of strtoll() altogether, and using direct comparisons, as Stefano suggests?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.