Sunday, November 12, 2017

Surreptitious Submodule Switch

During the last couple of days, we've transitioned all the third party libraries used by wxWidgets, such as libpng, libjpeg and so on, to use Git submodules instead of just subdirectories in the main repository. If you don't use Git to get the latest and greatestfor the appropriate definition of "great" wxWidgets, you don't need need to read further as it shouldn't affect you in any way except for resulting in faster and more frequent updates to these libraries (but still consider starting to use sources from Git to help us with testing!).

If you do use Git, you will notice that your next update, i.e. git pull or git fetch && git merge --ff-only origin/master, will delete all files in src/{expat, jpeg, png, tiff, zlib} directories. Do not be alarmed by this but do run

git submodule update --init
to initialize and get the latest contents of all the submodules. This will, unfortunately, take quite some time, and if you use a not too ancient version of Git (2.8 or later), you should be able to speed the process up significantly by doing
git fetch --recurse-submodules -j2
instead, where "2" could be replaced by any number up to 5 (higher would be useless with only 5 submodules).

During subsequent updates, if you notice any change to one of the submodules, you need to only rerun git submodule update (without the --init option) and it will be much faster. Other than that, your use of wxWidgets Git repository shouldn't have to change in any way, the only difference is now most of Git commands won't recurse into submodules, at least by default, so git grep, for example, won't find any matches in the subdirectories mentioned above by default. However mostly the new behaviour is more useful, and you can use the same --recurse-submodules option with a few Git commands to change it if really needed.

Of course, if you do find any problems due to the switch to submodules or third party libraries upgrades that have taken place together with it (we now use the latest versions of all of them, notably jumping from libjpeg 6b released in 1998 to 9b, released in 2016), please let us know on the mailing lists, as usual.

Sunday, May 28, 2017

Configure is now less forgiving

Just a word of warning: it was previously possibly to write ../configure --enable-bloordyblop and configure would happily run and just ignore the unknown option. This could be seen as being nicely lenient but, in fact, was much more often aggravating as it allowed typos in configure options to slip through, resulting in many "WTF are my library binaries still not optimised even though I did use --enable-optimize?". The answer is, of course, as previously mentioned, wxWidgets British roots: you were supposed to use --enable-optimise instead. But while sticking to the right spelling might be commendable, not giving any errors for the wrongalternative one is definitely not. Moreover, this was never intentional and happened only as an unfortunate side effect of how Autoconf AC_CONFIG_SUBDIRS()macro worked

And this has finally changed: since this recent commit, which will be part of upcoming 3.1.1 release, unrecognised configure options will result in an immediate error. And while the new behaviour is better, it does risk breaking a few of the existing build scripts, e.g. if you use obsolete options (such as --enable-compat24) or, indeed, if you made a typo in one of them. In this case, please just remove the options that don't exist any more (they were previously ignored anyhow) or fix the typos. And in the unlikely case when you really need to pass an unsupported option to wx configure script (why would you do this?), you can always explicitly use --disable-option-checking on the command line to continue doing so -- and you will even get an error if you make a typo in this one!

Friday, May 05, 2017

Our GSoC 2017 students and projects

After an average of one post every 6 months or so on this blog, good news just can't stop coming now, with a second post in just 3 days. This one is to announce that wxWidgets has been allocated two slots in this year Google Summer of Code program and Prashant Kumar and Jose Lorenzo will be working on adding support for multi-touch gestures and providing better integration with JavaScript in wxWebView this summer.

Congratulations to Prashant and Jose and thanks to everybody else who applied (but, unfortunately, couldn't be accepted) to work on wxWidgets and also to our mentors: Cătălin Răceanu, Mariano Reingart and Steven Lamerton. And good luck to all involved!

Tuesday, May 02, 2017

3.0.3 Released

We have finally, after a long delay, released 3.0.3, please see the announcement or go directly to the release page. As with the previous 3.0.x releases, there are no important new features in this release, but there are quite a few bug fixes as well as support for the relatively recent compiler, platforms and third-party libraries versions which were not yet (widely) available at the time of 3.0.2, so upgrading to it is strongly recommended for all 3.0 users, especially because it is so simple: the new release is 100% compatible with 3.0.2 and doesn't require any changes to your applications code or, if you are using shared libraries, not even recompiling it.

As always, thanks to everyone who has contributed to this release (at least 66 people according to git commit information, but certainly more in practice) and helped with preparing it, by building the binaries, documentation and testing it!

Monday, March 27, 2017

Last call for proposals for GSoC 2017

This is just a reminder that wxWidgets is one of the mentoring organizations in this year Google Summer of Code program and we are looking for proposals from motivated students with knowledge of C++ and interest for cross-platform development.

There is less than a week remaining before the deadline for submitting GSoC applications, so, if you are a student, or know of a student, interested in participating, please hurry up!

Sunday, February 19, 2017

Safer S...

I want, of course, to talk about "Safer Strings" today.


TL;DR: Add /DwxNO_UNSAFE_WXSTRING_CONV=1 to your compiler options today.


wxWidgets has had implicit conversion of wxString to const char* since the dawn of time (or about 1992, at any rate). This was always dangerous, as it allowed someone to accidentally write:

void show_and_free(const char* p) { ...; free(p); }
wxString s("...");
show_and_free(s);
with catastrophic consequences, but such situations were relatively rare and it was thought that the convenience of having this implicit conversion overweighted the dangers. This is also why when we added Unicode support later, we also added implicit conversion to const wchar_t* and, when we added "STL" build mode, in which interoperability with the standard library is increased further even at the price of backwards compatibility, we added implicit conversions to std::string and std::wstring as well.

Unfortunately, with the merge of ANSI and Unicode build modes in wxWidgets 3, another, much more dangerous, problem has appeared because in the new combined mode we can now have a string containing Unicode characters not representable in the current locale encoding. And converting such strings to either char* or std::string inevitably results in a loss of data in this case, e.g.

double convert_temperature_to_celsius(const char* p) {
    const char* end;
    double t = strtod(p, &end);
    return 5.*(t - 32)/9.;
}

wxString s = wxGetTextFromUser("Enter temperature");
convert_temperature_to_celsius(s);
could, confusingly, result in always returning -17.77777, corresponding to 0°F, if the user decided to terminate the temperature entry with "°F" to explicitly indicate the scale used and the current encoding couldn't represent the degree symbol (which is the case of e.g. CP1250 under Microsoft Windows). In this case, conversion of wxString to char* would fail and p would be just empty.

Of course, this wouldn't happen if the code just used wxString::ToDouble() directly, or used wxChar and wxStrtod(), or used UTF-8, capable of representing any Unicode character, as encoding (which is practically always the case under Unix systems nowadays). So there are a lot of ways to write this code correctly, but, unfortunately, it was still too simple to write it wrongly accidentally lose the data entered by the user in this case. Clearly, implicit conversions potentially losing data are a bad idea, but we couldn't just turn them off in wxWidgets 3, as it would have broken almost all the existing programs which, empirically, all used these conversions in many places.

For the same reason, we still won't be able to turn this conversion off by default, even in wxWidgets 3.2. However now we at least provide a way to opt-in into safer behaviour. The arguably less interesting part of the changes is that you can now change the value of the compile-time wxUSE_UNSAFE_WXSTRING_CONV option when building the library. It is set to 1 by default, for compatibility, but if you build wxWidgets for the use in your own project, you are strongly advised to set it to 0 to permanently disable the unsafe, in the sense described above, implicit conversions.

Many people, however, don't build their own library, but use the one provided by their package manager under Unix/macOS or download our MSW binaries. These official binaries will continue to provide the unsafe conversions for compatibility, but you can define wxNO_UNSAFE_WXSTRING_CONV when building your own project to disable their use in your code without rebuilding the library. This symbol can be just #define'd before including any wxWidgets headers, but it is better to define it globally, in the compiler options in your make- or project file: just add /DwxNO_UNSAFE_WXSTRING_CONV=1 to it. And the main point of this long post is to convince you that you NEED TO DO just that: please define wxNO_UNSAFE_WXSTRING_CONV for your code and fix the resulting compilation errors to ensure that you don't lose any data entered by the user.

Fixing the compilation errors will, generally speaking, involve doing one of two things:

  • Either stop using char* (or std::string in the STL build) entirely and use wxString directly.
  • Or convert it to wchar_t* (or std::wstring) or convert wxString to UTF-8 encoding which will never lose data, using methods such as utf8_str(), which is a convenient synonym for mb_str(wxConvUTF8), or ToStdString(wxConvUTF8).
Of course, if you really need to use the current locale encoding, e.g. because you call a C standard library function using it, you will still need to perform the conversion to it, using just plain mb_str() and there will still be a possibility of the conversion to it failing, but at least now it won't happen implicitly.

Thanks for reading all this and, if you jumped to the end, hoping to quickly find the conclusion instead of reading this wall of text, please see the conclusion in the very beginning!

Monday, June 13, 2016

How to Keep a Secret

If your program needs to ask the user for a password, e.g. to connect to a web site or a database, chances are that it proposes a way to remember this password and not have to enter it the next time. This is convenient for the users, but is quite difficult to implement in any more or less secure way and a lot of programs end up storing the passwords in plain text, or something almost indistinguishable from it, e.g. base64-encoded string, in wxConfig.

But now wxWidgets provides a better way to do it with the new wxSecretStore class. It is still as simple to use as wxConfig but uses the OS-provided password storage facility such as Microsoft Windows credentials vault or OS X keychain, for storing the secrets you confide to it. Here is how you would normally use it:

Currently there is not much more that can be done with this class, the only functionality not illustrated by this example is deleting a previously stored secret, but in the future we could extend it, notably to provide a way to also ask the user to enter the password using the OS-provided dialog. Let us know if you use wxSecretStore and if you see possible improvements, please don't keep them secret!