Crazy UB when casting to enum values in C++

Hi folks, this time it will be a kind of photo story! Something new this time, aaaaand I must type much less text!

It started a couple of day ago, when I saw following quiz on Twitter:

In C++20 given

enum A { e1=1, e2 } ;
enum class B { e1=1, e2 } ;

Which of the following invokes undefined behavior

A.
A a = (A)(3);
B.
A a = (A)(4);
C.
B b = (B)(std::numeric_limits<std::underlying_type<B>::type >::max());#Cplusplus #Cpp20 #CppPolls #Programming

— Shafik Yaghmour (@shafikyaghmour) August 29, 2018

My answer was: all of them of course, in C or C++98 they would be probably all fine, but who knows what crazy UB stuff did they prepare for us in C++20. So when seen logically, all of that stuff should be undefined behaviour! But wait, dind't I used extensions to enum ranges in some project in some framework by casting integers to enums? That did work ok, didn't it? Ok, it was couple of years ago, C++03 I suppose, but AFAIK nothing has changed in C++11 in that respect, so maybe we did it wrong all the time back than? So how did it work?

So I wasn't so sure anymore, and would say A+B are UB, C is something that C++11 introduced, so no idea, but probably UB too. But wait, all of them are UB again? Probably, but the trouble with that was that there wasn't such an answer in the quiz! Crazy!

When I saw the answer I was even more perplexed:

|
|
|
|
|
|
|
|
V

For an enum w/ a fixed underlying type all values of the underlying type are valid

For an enum w/o a fixed type, the range is limited and based on the values of enumerators, specified in [dcl.enum]p8

roughly limited to the bits needed to represent the values

— Shafik Yaghmour (@shafikyaghmour) August 29, 2018

What? Why 3 but not 4? And that numeric_limits<>::max() can't be right either! In a following tween the relevant spots in the standard were shown, and I read them, but was none the wiser - standardese isn't the lightest read on earth. ☹️

But before I gave up I remembered that I've seen something similar on Twitter already, namely in (accidently also cited) tweet by @lefticus:

I'm pretty sure I have this right, but this is Undefined Behavior, right?

enum struct Values {
val1 = 1,
val2 = 2
};

Values val = static_cast<Values>(3);

— Jason Turner (@lefticus) August 10, 2018

So had the same gut feeling as me, but he was corrected by some people well-versed in interpreting the standard (which I also happen to follow):

No, it is not. Enums with a fixed underlying type (which is int by default for enum class/struct) can have all the values of the underlying type. For enums without a fixed underlying type it gets more complicated.https://t.co/pVZoTBpIt2

— Miro Knejp (@mknejp) August 10, 2018

and:

In this particular case there is no UB even if it was an oldschool enum because 3 can be represented by the two bits required to store the enumerators 1 and 2.

— Miro Knejp (@mknejp) August 10, 2018

That was than even confirmed by @CppSage himself:

That's not UB. It's also perfectly fine for a regular enum. However, for a regular enum, casting the value 4 *would* be UB (even though 3 is okay). For an enum class/struct, casting the value 4 would *not* be UB.

— Matt Calabrese (@CppSage) August 10, 2018

This all explains it pretty well. But isn't that crazy? Binding logical range of a type to its underlying representation? I'd understand that if we were in the 80-ties, but in C++20 standard with all that lofty newfangled features? OK, I suppose it was always like that in C, but I'm too lazy to check it, sorry.... 😩

BTW, now I've got an idea why this enum casting in a distant project might even have been working - we used Visual Studio compiler! And I dimly remember that there were some Microsoft extension for enums setting int as their underlying type. Was it so? For that I'd have to check my own blogpost from last year, but frankly, I cannot be bothered. 😩 That project has died already long ago.

TL;DR: Twitter is a good place to learn about C++, I learn almost every day!

Scripting my Vim Editor

As an inveterate vim user the first thing (or one of the first things) I'd do when starting a new project under Windows is installing vim to use it for searching, grapping and editing logfiles when I'm bugfixing. Or just a to use it as a general viewer for all sorts of files.

Typically I'd set up my toolbar buttons (for vim 7.4) like that:

"" Caution: Needs 18x18 bitmaps in "C:\Program Files (x86)\Vim\vim73\bitmaps" !!!
:amenu ToolBar.-SEP- :
:tmenu ToolBar.tabedit Open new tab (mrkkrj)
:amenu ToolBar.tabedit :tabedit<cr>

:tmenu ToolBar.darklight Switch color themes (mrkkrj)
:amenu ToolBar.darklight :colo zellner<cr>
:tmenu ToolBar.lightdark Switch color themes (mrkkrj)
:amenu ToolBar.lightdark :colo torte<cr>

:tmenu ToolBar.smallfont Smaller font (mrkkrj)
:amenu ToolBar.smallfont :set guifont=Lucida_Console:h9<cr>
:tmenu ToolBar.bigfont Bigger font (mrkkrj)
:amenu ToolBar.bigfont :set guifont=Lucida_Console:h10<c>

This gives me my standard button toolbar with buttons for switching fonts and and colors from big to small and from dark to light, plus a button for opening new tabs:

Somehow this was always enough, beacuse I just used my default dark scheme  plus one more dark and an alternative light one. As you know the colors depend on the monitir you are using and the room you are sitting in, so in my new project I wanted to toggle through several schemes and font sizes before I settle down with my favorite. Thus I introduced following functions:

:tmenu ToolBar.darklight Switch color themes (mrkkrj)
:amenu ToolBar.darklight :call ToggleLightScheme()<cr>
:tmenu ToolBar.lightdark Switch color themes (mrkkrj)
:amenu ToolBar.lightdark :call ToggleDarkScheme()<cr>

:tmenu ToolBar.smallfont Smaller font (mrkkrj)
:amenu ToolBar.smallfont :set guifont=Lucida_Console:h9<cr>
:tmenu ToolBar.bigfont Bigger font (mrkkrj)
:amenu ToolBar.bigfont :call ToggleBigFontSize()<c>

Next thing is to write the actual functions to toggle between dark and light color schemes. What I did was toggling between 2 light and 2 dark color schemes like that:

:function ToggleDarkScheme()
:  if exists('g:colors_name')
:    if g:colors_name == 'evening'
:      colo darkblue
:    else
:      colo evening
:  endif
:  else
:      colo evening
:  endif
:endfunction

:function ToggleLightScheme()
:  if exists('g:colors_name')
:    if g:colors_name == 'zellner'
:      colo delek
:    else
:      colo zellner
:  endif
:  else
:      colo delek
:  endif
:endfunction

Toggling of fonts had to be done a little different, because there's no global variable that vim would set when fonts are changing like the g:colors_name above. So I had to introduce my own: g:guifonts_name:

let g:guifonts_name = 'Lucida_Console:h10'

:function ToggleBigFontSize()
:    if g:guifonts_name == 'Lucida_Console:h10'
:      set guifont=Lucida_Console:h12
:      let g:guifonts_name = 'Lucida_Console:h12'
:    else
:      set guifont=Lucida_Console:h10
:      let g:guifonts_name = 'Lucida_Console:h10'
:  endif
:endfunction

Admittedly this is not a pretty and general solution: if I needed more colors or fonts I'd have to add more ugly if-else clauses. The ceneral soultion would be of course  to create a local array of color schemes and cycle through it like it is shown here*. But "form follows function..." and "use before reuse..." 😉 - and frankly, I didn't have time for that, vimscript's syntax** is pretty weird.

--
* "Switch Color Schemes" in Vim Tips Wiki: http://vim.wikia.com/wiki/Switch_color_schemes

** There some good intros you can use to deepen your knowledge of vim scripting:

• "Five Minute Vimscript" by Andrew Scala: http://andrewscala.com/vimscript/
• "Scripting the vim editor"series by Damian Conway: https://www.ibm.com/developerworks/library/l-vim-script-1/index.html
• The "Learn Vimscript the Hard Way" book online: http://learnvimscriptthehardway.stevelosh.com/

More on Casablanca/cpprestdsk - Design and Comparisons

After I finished my Casablanca (aka C++ REST SDK)* project for some time then, I noticed** a new Boost library: Boost.Beast***, a library implementing: "HTTP and WebSocket built on Boost.Asio in C++11". 

That sounded interesting so I had a quick look at it, and I even found (surprise, surprise) the design rationale and comparison with other HTTP libraries. Because of my previous involvement with Casablanca* I simply had to read it. So here is my take on Beasts's critique and some closing discussion of Casablanca's* design and how I see it.

My involvement with Casablanca*/C++ REST-SDK code...☺

Let us start with a lengthy citation from Beast's analysis of Casablanca*, where the author lists all the missing customization points of the library:

"It is clear from this declaration that the goal of the message model in this library is driven by its use-case (interacting with REST servers) and not to model HTTP messages generally. We note problems similar to the other declarations:

• There are no compile-time customization points at all. The only customization is in the concurrency::streams::istream and concurrency::streams::ostream reference parameters. Presumably, these are abstract interfaces which may be subclassed by users to achieve custom behaviors. 

• The extraction of the body is conflated with the asynchronous model. 

• No way to define an allocator for the container used when extracting the body. 

• A body can only be extracted once, limiting the use of this container when using a functional programming style. 

• Setting the body requires either a vector or a concurrency::streams::istream. No user defined types are possible. 

• The HTTP request container conflates HTTP response behavior (see the set_response_stream member). Again this is likely purpose-driven but the lack of separation of concerns limits this library to only the uses explicitly envisioned by the authors."

Then the author restates it in a more concise manner:

"The general theme of the HTTP message model in cpprestsdk is "no user definable customizations". There is no allocator support, and no separation of concerns. It is designed to perform a specific set of behaviors. In other words, it does not follow the open/closed principle.

Tasks in the Concurrency Runtime operate in a fashion similar to std::future, but with some improvements such as continuations which are not yet in the C++ standard. The costs of using a task based asynchronous interface instead of completion handlers is well documented: synchronization points along the call chain of composed task operations which cannot be optimized away. See: A Universal Model for Asynchronous Operations (Kohlhoff)."

Let me state my opinion bluntly: I didn't miss these customization features at all during my almost 3 years long involvement with Casablanca*! The framework just did its work as it should, we could use it without much hassle and it performed reasonably good under load on Windows - probably through its usage of completion ports (Boost.Asio is only used on Mac Os and Linux).

OK, there was a single time where one of the above concerns did cause problems, namely:

• A body can only be extracted once, limiting the use of this container when using a functional programming style,

but I solved it by setting the data into the message back again. Mischief managed 😈, work can be continued! You could say it's not very functional programming style, but we are not in the academy but in real life.

On the other side the Boost.Beast itself library seems a little hard to use, and more like a base for another libraries than a independent library on its own, as it is stated in the project's own FAQ:

"It is not the intention of the library to provide turn-key solutions for specific HTTP or WebSocket use-cases. Instead, it is a sensible protocol layering on top of Boost.Asio which retains the Boost.Asio memory management style and asynchronous model."

So OK, we must be aware of Casablanca's* limitations, but for the real REST use case they somehow carried no weight.

TL;DR: I cannot really relate to the critique stated in the comparison, for us Casablanca worked out pretty well in general and the product we build with it is alive and kicking!

Note: Here and here I found quite interesting results of a security review of Boost.Beast by Bishop Fox. They found vulnerabilities, and I don't want to even think about their analysis of Casablanca*! Fortunately our product was set up forca more or less trusted environment. But this could be maybe a material for a separate blog post.

--
* Casablanca is the old code name for Microsoft's C++ REST SDK and I'll use it in the rest of that post, because it rolls better off the tongue than cpprestsdk! Besides during the years I grew accustomed to it and even a little nostalgic...

** to be more specific, I noticed it through Meeting C++'s library reviews initiative!

*** see "Beast: Version 100, ACCEPTED to Boost!" here.

QLabel swallows mouse clicks in RichText mode?

As I already said in the title:

QLabel swallows mouse clicks when in rich text mode, what can I do? Help! 

I ran into that problem in my new project just yesterday* and will document the solution here, because searching the Internet didn't result in a thorough solution 😞.
 
Actually, I ran into two problems with Qt (I'm on the 5.9 version now). It started with my desire to change line spacing in the custom icon widget I inherited with a pile of legacy code in my new project. Somehow it wasn't possible with the standard C++ API, so I resorted to the proven Qt workaround - CSS stylesheets.

Oftentimes stylesheet support implements manipulations and parametrizations not available through C++ and this case is one of them. Because setting the stylesheet directly didn't seem to work, the equivalent rich text string would do the work (note that the line-height property is stated in percent values):

  QString txt = "<p style=\"line-height:80;\">text text text</p>";

That trick seemed to have removed the problem, but in reality I just didn't notice the consecutive problem I created with this!

The text I wanted to space was a subscript under an icon, which was set as a bitmap in the class containing both the icon and the text. What I didn't notice was the fact, that a touch/click on the icon would start processing but when the user clicked/touched the re-spaced text it wouldn't! And of course falling back to a non-rich text would fix that problem!

As it turned out, in rich text mode QLabel wouldn't receive any MouseRelease events! First of all I found a slew of Qt bug-reports: 12982, 2028, 24375, all of them rejected or simply not fixed. So is it a Qt bug? Why it's not fixed? And what is a workaround for it? So I started to search the web for hints. One info I found was a short explanation by Thiago Macieira:

"Probably not a bug. Do you get the mousePressEvent? The release event is always sent to the same widget that accepted the mouse release. And QLabel with rich text might contain links, so it may need to handle mouse presses."

Needled to say I was rather devastated - this seems to be the expected behavior, and if you want to change it, you have to reimplement it!!! Needless to say, I wasn't inclined to do so. I was slowly approaching desperation, but then I found another hint: "you could try ... Qt::WA_TransparentForMouseEvents". And that put every piece of the puzzle in its place for me:

1. As Qt-documentation says on Qt::WA_TransparentForMouseEvents:

"When enabled, this attribute disables the delivery of mouse events to the widget and its children. Mouse events are delivered to other widgets as if the widget and its children were not present in the widget hierarchy; mouse clicks and other events effectively "pass through" them. This attribute is disabled by default."

2. QLabel might contain links in general, but in out case we just have some plain text which has to be styled, ergo mouse events are of no use to it!

3. We cannot force QLabel to not accept() the mouse events in that case (alas), but we can cut it off from them, so that it won't steal MouseRelease and its parent widget will still receive it.

So I wrote a following method for setting the labels of icons:

  void CIconCell::SetIconLabel(const QString& label)
  {
    // correct spacing in double row texts
    // - cannot be done with std. Qt-API!
    m_Text->setTextFormat(Qt::RichText);
    m_Text->setAttribute(Qt::WA_TransparentForMouseEvents, true); // otherwise rich-text QLabel blocks mouse events!

    auto richTxt = QString("<p style=\"line-height:%1;\">").arg(m_LineSpacingRatio);
    richTxt += label;
    richTxt.replace("\n", "<br />");
    richTxt += "</p>";

    m_Text->setText(richTxt);
  }

PS: somehow the code formatter seems to interpret <br /> as line break, it should be: richTxt.replace("\n", "<br />");

TL;DR;
So essentially all the information was out there, you only had to connect the dots. But this isn't cost free, so I publish the ready solution for the good of all Qt programmers 😉.

---
* OK, not entirely true, but at least I started to write this post on the next day...