lilypond-devel
[Top][All Lists]
Advanced

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

Re: GOP-PROP 5: build system output (final)


From: Carl Sorensen
Subject: Re: GOP-PROP 5: build system output (final)
Date: Tue, 9 Aug 2011 15:28:21 -0600



On 8/9/11 2:04 PM, "Wols Lists" <address@hidden> wrote:

> On 09/08/11 20:44, Neil Puttock wrote:
>> On 9 August 2011 20:21, Reinhold Kainhofer <address@hidden> wrote:
>> 
>>>> So having only 9 warnings in our codebase (four of which are in the
>>>> lexer/parser, which hardly anyone of us really understands!) is amazing.
>> There are many more warnings (> 180) if you're compiling a 64-bit
>> binary.  They could be silenced via casting, but Han-Wen isn't in
>> favour of that approach (http://codereview.appspot.com/1724041/):
>> 
>> "* Why are all the casts there?  Is this a 64 bit compiler thing?  Lily
>> compiles
>> virutally without warnings over here (core duo, gcc 4.4.4).  I think all the
>> casting hinders readability, so I propose to not add casts unless necessary.
>> If
>> the warnings bother you, add a targeted -Wno-xxx option to the Makefile.  I
>> doubt that there are any cases where there is the risk of a real error."
>> 
> Hmmm ...
> 
> "Is this a 64 bit compiler thing?" - not really. It's an "int" thing in
> all probability. sizeof(int) is explicitly undefined. As for there
> aren't any cases where there is a real risk of error, well I don't know
> of any compilers where sizeof(int) = 1, but that would be perfectly
> legal ...
> 
> If you shouldn't use cast, you shouldn't use int. Which is a shame,
> because I think int is defined to be "the natural length of the platform
> you're running on" ie it's the most efficient integer variant to use.
> 
> Imho (as I've said before) *all* warnings should be explained or fixed.
> Papering over the cracks by hiding them is likely to result sooner or
> later in a real problem slipping through (like a compiler defining
> sizeof(int) as 1 :-)

Looking at Han-Wen's comment in context, I think the best way to approach
this is to do as he suggests, which is to define v_size back to int.

Thanks,

Carl




reply via email to

[Prev in Thread] Current Thread [Next in Thread]