lilypond-devel
[Top][All Lists]
Advanced

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

RE: Another patch


From: lilypond
Subject: RE: Another patch
Date: Sun, 10 May 2020 16:58:05 +0200

Dan, 

As you already did see, I did not a simple cast, but instead my solution is 
raising an error in those cases where a simple cast would change the value 
tested.
However, I will follow your suggestion, and break the patch in parts.
I also will pay attention to your particular example, as I think this is the 
only case of the now solved warnings where the int in a next function is casted 
to a smaller type.

Jaap de Wolff

> -----Oorspronkelijk bericht-----
> Van: Dan Eble <address@hidden>
> Verzonden: Sunday, May 10, 2020 4:31 PM
> Aan: address@hidden
> CC: address@hidden
> Onderwerp: Re: Another patch
> 
> On May 10, 2020, at 08:11, address@hidden wrote:
> >
> > I did replace all implicit casts to an int by a inline function,
> > checking if the value is valid, and then casting  to int.
> >
> > Together with my previous patch now all but one compiler warnings are
> > solved.
> 
> Jaap,
> 
> I love the fact that you are taking the initiative to work on these.  I 
> haven't
> reviewed them thoroughly, but my first comment is a note of caution.  A
> couple of warnings, like the printf one, are just simple oversights; however,
> many of the warnings that remain in LilyPond are the tip of an iceberg.
> 
> There was a discussion on the developer list about simply casting to silence
> warnings, but more developers were in favor of leaving the warnings in until
> someone is motivated to fix them properly.
> 
> I commend you that your work is not just simply casting, but in at least some
> cases, it still doesn't appear to be going to the depth these issues deserve. 
>  For
> example, the number of tracks in a MIDI file is a 16-bit number[1], so 
> clipping
> to INT_MAX isn't quite right.  (I've got an old branch where I've fixed the
> header generation to use uint16_t, but it's still missing code to warn 
> properly
> when the number of tracks needs to be clipped.  I'll try to rebase that to 
> save
> you the work.)
> 
> I encourage you to sort the simple and obvious fixes (like the printf one) 
> into
> one commit, and the other cases into their own commits.  It will limit the
> consequences if we later have to revert a change because of a subtle bug that
> escaped regression testing.
> 
> Regards,
>
> Dan
> 
> [1]
> http://www.music.mcgill.ca/~ich/classes/mumt306/StandardMIDIfileformat.ht
> ml#BM2_1




reply via email to

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