What Exactly Do "Ib" and "Ub" Mean

What exactly do IB and UB mean?

IB: Implementation-defined Behaviour. The standard leaves it up to the particular compiler/platform to define the precise behaviour, but requires that it be defined.

Using implementation-defined behaviour can be useful, but makes your code less portable.

UB: Undefined Behaviour. The standard does not specify how a program invoking undefined behaviour should behave. Also known as "nasal demons" because theoretically it could make demons fly out of your nose.

Using undefined behaviour is nearly always a bad idea. Even if it seems to work sometimes, any change to environment, compiler or platform can randomly break your code.

What do these x86 Assembly instruction codes mean?

You'll want to see Intel® 64 and IA-32 Architectures Software Developer Manuals.

"slash x" denotes that part of the instruction is encoded in the opcode (reg) part of the modr/m byte. See Vol 2A Chapter 2 INSTRUCTION FORMAT.

"ib" and "id" mean "immediate byte" and "immediate dword" respectively. You can see all the abbreviations in Vol 2A Appendix A.2 OPCODE MAP / KEY TO ABBREVIATIONS.

c++ pointer and variable address switch of value, why?

Can I have an explanation? I didn't find any documentation about this.

Main documentation in this case is C++ standard, though it is sometimes not to easy to find and comprehend information from there. So short version in your case - you can only subtract or add integers to a pointer when resulting pointer would point to an element in the same array or pointing to the fictitious element behind the last (in this case it is illegal to dereference your pointer). For this purpose single variable is treated like one element array (so for pointer to single variable you can basically only do pointer + 1). All other hacky tries to access variables through magic with pointer arithmetics are illegal and lead to Undefined Behavior.

Details about UB you can find here What exactly do "IB" and "UB" mean?

What is the error in my c code?

Your char *string should be const char *string (but it is immutable); or better char string[] = .... and then declare another variable char *s = string;, and loop and step s instead of string

Why converting 'out of range integer to integer' leads to IB, but converting 'out of range floating-point to integer' leads to UB?

From the point of view of the Standard, the question of whether to classify something as Implementation-Defined Behavior and Undefined Behavior depends on whether all implementations should be required to document a behavior generally consistent with the semantics of the language, regardless for cost or usefulness. There was no need to mandate that implementations process actions in ways their customers would find useful, because it was expected that implementations allowed to behave in such fashion would do so with or without a mandate. Consequently, it was seen as better to characterize as Undefined Behavior useful actions which implementations might process 100% consistently, than to characterize as Implementation-Defined actions which might sometimes be impractical to implement consistently.

Note that for an implementation to treat an action as having documented behavior could sometimes have costs that might not be obvious. Consider, for example:

int f1(int x, int y);
int f2(int x, int y, int z);
void test(int x, unsigned char y)
{
  short temp = x/(y+1);
  if (f1(x,y))
    f2(x,y,temp);
}

On platforms where the conversion to short would always execute without side effects, or on implementations that were allowed to treat out-of-range conversions as Undefined Behavior, the computation of x/(y+1) and conversion to short could be deferred until after the call to f1, and skipped altogether if f1 returns zero. Such transformation could affect the behavior of a signal raised by the conversion, however, and would thus not appear to be allowable under the Standard on implementations where the conversion could raise a signal.

On the other hand, while it may be useful to have implementations raise a signal in case of an out-of-bounds conversion, such signals would mainly be useful in situations where quality of diagnostics was viewed as more important than performance. Implementations where performance was more important would be free to make optimizations like the above if they processed the conversion as having no side effects, and it seemed likely that the latter course of action would be practical on all platforms.

There were platforms where the fastest way of converting a float to an int will trap; as noted, the possibility that an action may trap would make classification as Implementation-Defined behavior expensive. While it is unlikely that there would have been any platforms where it would have been impractical to process a conversion from e.g. float to short as a conversion from float to int, followed by a conversion from int to short, there are platforms where that may not be the most useful behavior (e.g. if a platform can at no extra cost peg the result of such a conversion to the range of the target type, that may be more useful than a conversion to int and then the target type). Even if the authors of the Standard would have expected and intended that conversions from floating-point types to small integer types never yield unsequenced traps for any values which are within range of int, the Standard classifies as UB general actions which might behave unpredictably in some cases but in a predictable implementation-specific fashion in others, without any effort to identify specific cases where they should behave predictably.

The latter principle is perhaps best illustrated by examining the way left shift was described in C89 and C99. There is no reason why x << 0 shouldn't yield x for all integer values of x, and the way C89 specified the behavior would do precisely that. The C89 spec, however, specified behavior in some cases where it may be useful to allow some implementations to behave in a different, and not necessarily predictable, fashion. C99 makes no effort to identify situations where all implementations should treat left shifts of negative numbers the same way as C89 did, because the authors expected that all implementations would treat such cases in C89 fashion with or without a mandate.

Why did the range based 'for' loop specification change in C++17?

Using

auto __begin = begin_expr, __end = end_expr;

requires both begin_expr and end_expr to return the same type. This means you cannot have a sentinel iterator type that is different from the beginning type. Using

auto __begin = begin_expr ;
auto __end = end_expr ;

fixes that issue while proving full backwards compatibility with C++14.

Strange exception phenomenon in Windows 7

Dereferencing a pointer that doesn't point to an object (for example, an uninitialized pointer) results in undefined behavior.

This means that anything can happen. Typically, writing via an uninitialized pointer will cause your program to crash--either immediately or at some point in the future. It is conceivable that your program could appear to continue running correctly, but you can never rely on that.

What exactly is the presentation engine in Vulkan jargon?

Presentation engine in Vulkan is an external component that manages and accepts the rendered image you made in Vulkan (assumably) for the purposes of presentation to the user.

From another POV, it is whatever the interface gives you. Which is vkAcquireNextImageKHR, vkQueuePresentKHR, etc., in the case of the VK_KHR_swapchain extension. Other extensions can be made, as presentation engines that operate fundamentally differently emerge (e.g. VK_KHR_display_swapchain).

VK_KHR_swapchain, requires VK_KHR_surface, which is specialized to VK_KHR_win32_surface, VK_KHR_xlib_surface, etc. So you can bet those are the APIs the driver talks to underneath. I.e. it talks to Win32 API (aka Windows API), probably to the GDI component (but possibly to the DXGI swapchain). On linuxes + VK_KHR_xlib_surface, it would talk to X server. And so on... which inevitably has to end up in the hands of the windowing manager such as the DWM or Compiz.

---

Related Topics