... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.
Correct string formatting for:
2/15 %d + enum => %d + int
3/15 %lld + int64_t => %lld + long long
4/15 %d + int64_t => %lld + long long
5/15 %d + double => %f + double
6/15 %d + int32_t => %d + int
7/15 %d + intptr_t => %p + void*
8/15 gint, guint
9/15 %d + long => %ld + long
10/15 %n + int => %d + int
11/15 %x + int => %x + unsigned int
12/15 %f + int => %d + int
13/15 %S + wxChar* => %s + wxChar*
14/15 %d + size_t => %d + int
15/15 %d + size_t => %lld + long long
"The functions wxString::Format, wxString::Printf (and others indirectly) have become stricter about parameter types that don't match (format specifier vs. function parameters). So the bugs (that were already present in audacity before) become visible in wx3.0 as error message dialogs. I've checked all occurrences of Printf, wxPrintf, PrintfV, Format, FormatV, wxLogDebug and wxLogError systematically and made the type match."
Note (9/15): In TrackPanel.cpp, ExportMP2.cpp and CompareAudioCommand.cpp this patch supersedes related change done in r13466 because the new solution requires fewer casts and therefore simplifies the code.
Note: Many .po files are affected, and we need to be very careful about this. Incorrect "%d" and similar in translation files may lead to crashes in those languages (only). This is something we should actually have been more careful about in the past. We need to write a script to check that the "%d" and similar format specifiers match between English and translation.
He wanted to help so I asked if he wanted to track them down. He agreed and
found more than I probably would have. And he said there were more, but the
rest were questionable and since he works on Windows, wasn't able to actually
test.
I give a few of the ones he did find a go and they do indeed get rid of the
assertions.
(Basically, a 64-bit/32-bit issue, easily resolved with a typecast.)
Refer to bugzilla for discussion, but, to summarize, this removes any writing of ID3V1 tags. ID3V1 tags will still be imported, but they will be written as ID3V2 tags.
