From the standard, 7.21.6.2p10 (`(f)scanf`, applies to the whole family):

&gt; … If this object does not have an appropriate type, or **if the result of the conversion cannot be represented in the object, the behavior is undefined**.

Looks like another reason to be very cautious with the `scanf` family. The `strtoXX` functions have a fully defined behaviour. They return `LONG_MAX` etc. for too large input and set `errno == ERANGE`. So if you need exact information, tokenise the input manually and use these functions for conversion. Another benefit: better error handling.


Is it possible, using the [fetch API][1], to set default headers for every single request?   
What I want to do is set an `Authorization` header whenever there is a json web token in the `localStorage`. My current solution is to set the headers with this function: 
&lt;!-- language: lang-js --&gt;

    export default function setHeaders(headers) {
    	if(localStorage.jwt) {
    		return {
    			...headers,
    			&#39;Authorization&#39;: `Bearer ${localStorage.jwt}`
    		}
    	} else {
    		return headers;
    	}
    }

Setting the headers in a fetch request would then look like this: 

    return fetch(&#39;/someurl&#39;, {
			method: &#39;post&#39;,
			body: JSON.stringify(data),
			headers: setHeaders({
				&#39;Content-Type&#39;: &#39;application/json&#39;
			})
		})


But there has to be a better way to do this. I&#39;m currently developing a React/Redux/Express app if that is of any help.
  [1]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

Set default header for every fetch() request

It will be the best explain in on example

`expected(someNumber).toBe(1).or.toBe(-2).or.toBe(22) // expect result is 1 or -2 or 22`

This is bad syntax, but can do sth like that in jest?

Logical OR for expected results in Jest

When `sscanf()` or another function from the `scanf` family is given a sequence of digits whose converted value exceeds the maximum value of the target integer type,  

* should the conversion be considered to have failed? 
* is the behavior defined at all?

 

Does sscanf(&quot;123456789123456789123456789&quot;, &quot;%d&quot;, &amp;n) have defined behavior?

When <code>sscanf()</code> or another function from the <code>scanf</code> family is given a sequence of digits whose converted value exceeds the maximum value of the target integer type,
<ul>
<li>
should the conversion be considered to have failed?
</li>
<li>
is the behavior defined at all?
</li>
</ul>

I&#39;m currently in the process of writing a tree enumerator where I&#39;ve come across the following problem:

I&#39;m looking at masked bitsets, i.e. bitsets where the set bits are a subset of a mask, i.e. `0000101` with mask `1010101`. What I want to accomplish is increment the bitset, but only with respect to the masked bits. In this example, the result would be `0010000`. To make it a bit clearer, extract only the masked bits, i.e. `0011`, increment them to `0100` and distribute them to the mask bits again, giving `0010000`.

Does anybody see an efficient way to do this, short of implementing the operation by hand using a combination of bitscans and prefix masks?



Incrementing &#39;masked&#39; bitsets

Is it undefined behavior to print null pointers with the `%p` conversion specifier?

&lt;!-- language: C --&gt;

    #include &lt;stdio.h&gt;
    
    int main(void) {
        void *p = NULL;
        
        printf(&quot;%p&quot;, p);
        
        return 0;
    }
    

The question applies to the C standard, and not to C implementations.

Printing null pointers with %p is undefined behavior?

Given this code:

    #include &lt;string.h&gt;
    
    int equal4(const char* a, const char* b)
    {
        return memcmp(a, b, 4) == 0;
    }
    
    int less4(const char* a, const char* b)
    {
        return memcmp(a, b, 4) &lt; 0;
    }

GCC 7 on x86_64 introduced an optimization for the first case (Clang has done it for a long time):

        mov     eax, DWORD PTR [rsi]
        cmp     DWORD PTR [rdi], eax
        sete    al
        movzx   eax, al

But the second case still calls `memcmp()`:

        sub     rsp, 8
        mov     edx, 4
        call    memcmp
        add     rsp, 8
        shr     eax, 31

Could a similar optimization be applied to the second case?  What&#39;s the best assembly for this, and is there any clear reason why it isn&#39;t being done (by GCC or Clang)?

See it on Godbolt&#39;s Compiler Explorer: https://godbolt.org/g/jv8fcf

Why is memcmp(a, b, 4) only sometimes optimized to a uint32 comparison?

I&#39;m reading through some emulator code and I&#39;ve countered something truly odd:

    switch (reg){
        case &#39;eax&#39;:
    	/* and so on*/
    }

How is this possible? I thought you could only `switch` on integral types. Is there some macro trickery going on?


This source code is switching on a string in C. How does it do that?

When you have string in C, you can add direct hex code inside.

    char str[] = &quot;abcde&quot;; // &#39;a&#39;, &#39;b&#39;, &#39;c&#39;, &#39;d&#39;, &#39;e&#39;, 0x00
    char str2[] = &quot;abc\x12\x34&quot;; // &#39;a&#39;, &#39;b&#39;, &#39;c&#39;, 0x12, 0x34, 0x00

Both examples have 6 bytes in memory. Now the problem exists if you want to add value `[a-fA-F0-9]` after hex entry.

    //I want: &#39;a&#39;, &#39;b&#39;, &#39;c&#39;, 0x12, &#39;e&#39;, 0x00
    //Error, hex is too big because last e is treated as part of hex thus becoming 0x12e
    char problem[] = &quot;abc\x12e&quot;;

Possible solution is to replace after definition.

    //This will work, bad idea
    char solution[6] = &quot;abcde&quot;;
    solution[3] = 0x12;

This can work, but it will fail, if you put it as `const`.

    //This will not work
    const char solution[6] = &quot;abcde&quot;;
    solution[3] = 0x12; //Compilation error!

How to properly insert `e` after `\x12` without triggering error?

---
Why I&#39;m asking? When you want to build *UTF-8* string as constant, you have to use hex values of character if it is larger than ASCII table can hold.

How to properly add hex escapes into a string-literal?

I have very frequently seen people discouraging others from using `scanf` and saying that there are better alternatives. However, all I end up seeing is either *&quot;don&#39;t use `scanf`&quot;* or *&quot;here&#39;s a correct format string&quot;*, and never any examples of the *&quot;better alternatives&quot;* mentioned.

For example, let&#39;s take this snippet of code:

    scanf(&quot;%c&quot;, &amp;c);

This reads the whitespace that was left in the input stream after the last conversion. The usual suggested solution to this is to use:

    scanf(&quot; %c&quot;, &amp;c);

or to not use `scanf`.

Since `scanf` is bad, what are some ANSI C options for converting input formats that `scanf` can usually handle (such as integers, floating-point numbers, and strings) without using `scanf`?

What can I use for input conversion instead of scanf?

I have come across the below C++ program ([source][1]):

    #include &lt;iostream&gt;
    int main()
    {
        for (int i = 0; i &lt; 300; i++)
            std::cout &lt;&lt; i &lt;&lt; &quot; &quot; &lt;&lt; i * 12345678 &lt;&lt; std::endl;
    }

It looks like a simple program and gives the correct output on my local machine i.e. something like:

    0 0
    1 12345678
    2 24691356
    ...
    297 -628300930
    298 -615955252
    299 -603609574
    
But, on online IDEs like [codechef][2], it gives the following output:

    0 0
    1 12345678
    2 24691356
    ...
    4167 -95167326
    4168 -82821648
    4169 -7047597

Why doesn&#39;t the `for` loop terminate at 300? Also this program always terminates on `4169`. Why `4169` and not some other value?

  [1]: https://ideone.com/7F88MV
  [2]: https://www.codechef.com/ide

Program behaving strangely on online IDEs

I&#39;ve been using `std::memcpy` to circumvent *strict aliasing* for a long time.

For example, inspecting a `float`, like [this](https://stackoverflow.com/a/17790026/8157187):

    float f = ...;
    uint32_t i;
    static_assert(sizeof(f)==sizeof(i));
    std::memcpy(&amp;i, &amp;f, sizeof(i));
    // use i to extract f&#39;s sign, exponent &amp; significand

However, this time, I&#39;ve checked the standard, I haven&#39;t found anything that validates this. All I found is [this](http://eel.is/c++draft/basic.types#2):

&gt; For any object (other than a potentially-overlapping subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes ([intro.memory]) making up the object can be copied into an array of char, unsigned char, or std​::​byte ([cstddef.syn]).&lt;sup&gt;40&lt;/sup&gt; If the content of that array is copied back into the object, the object shall subsequently hold its original value. [ Example:
&gt;
    #define N sizeof(T)
    char buf[N];
    T obj;                          // obj initialized to its original value
    std::memcpy(buf, &amp;obj, N);      // between these two calls to std​::​memcpy, obj might be modified
    std::memcpy(&amp;obj, buf, N);      // at this point, each subobject of obj of scalar type holds its original value
&gt;— end example ]

and [this](http://eel.is/c++draft/basic.types#3):
&gt; For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a potentially-overlapping subobject, if the underlying bytes ([intro.memory]) making up obj1 are copied into obj2,&lt;sup&gt;41&lt;/sup&gt; obj2 shall subsequently hold the same value as obj1. [ Example:
&gt;
    T* t1p;
    T* t2p;
    // provided that t2p points to an initialized object ...
    std::memcpy(t1p, t2p, sizeof(T));
    // at this point, every subobject of trivially copyable type in *t1p contains
    // the same value as the corresponding subobject in *t2p

&gt; — end example ]

So, `std::memcpy`ing a `float` to/from `char[]` is allowed, and `std::memcpy`ing between the same trivial types is allowed too.

Is my first example (and the linked answer) well defined? Or the correct way to inspect a `float` is to `std::memcpy` it into a `unsigned char[]` buffer, and using `shift`s and `or`s to build a `uint32_t` from it?

----------

Note: looking at `std::memcpy`&#39;s guarantees may not answer this question. As far as I know, I could replace `std::memcpy` with a simple byte-copy loop, and the question will be the same.

Is std::memcpy between different trivially copyable types undefined behavior?

I know that an *&quot;undefined behaviour&quot;* in C++ can pretty much allow the compiler to do anything it wants. However, I had a crash that surprised me, as I assumed that the code was safe enough.

In this case, the real problem happened only on a specific platform using a specific compiler, and only if optimization was enabled.

I tried several things in order to reproduce the problem and simplify it to the maximum. Here&#39;s an extract of a function called `Serialize`, that would take a bool parameter, and copy the string `true` or `false` to an existing destination buffer.

Would this function be in a code review, there would be no way to tell that it, in fact, could crash if the bool parameter was an uninitialized value?

    // Zero-filled global buffer of 16 characters
    char destBuffer[16];
    
    void Serialize(bool boolValue) {
        // Determine which string to print based on boolValue
        const char* whichString = boolValue ? &quot;true&quot; : &quot;false&quot;;
        
        // Compute the length of the string we selected
        const size_t len = strlen(whichString);
        
        // Copy string into destination buffer, which is zero-filled (thus already null-terminated)
        memcpy(destBuffer, whichString, len);
    }

If this code is executed with clang 5.0.0 + optimizations, it will/can crash.

The expected ternary-operator `boolValue ? &quot;true&quot; : &quot;false&quot;` looked safe enough for me, I was assuming, &quot;Whatever garbage value is in `boolValue` doesn&#39;t matter, since it will evaluate to true or false anyhow.&quot;

I have setup a [Compiler Explorer example](https://godbolt.org/z/DoFmhA) that shows the problem in the disassembly, here the complete example. *Note: in order to repro the issue, the combination I&#39;ve found that worked is by using Clang 5.0.0 with -O2 optimisation.*

    #include &lt;iostream&gt;
    #include &lt;cstring&gt;
    
    // Simple struct, with an empty constructor that doesn&#39;t initialize anything
    struct FStruct {
        bool uninitializedBool;
        
       __attribute__ ((noinline))  // Note: the constructor must be declared noinline to trigger the problem
       FStruct() {};
    };
    
    char destBuffer[16];
    
    // Small utility function that allocates and returns a string &quot;true&quot; or &quot;false&quot; depending on the value of the parameter
    void Serialize(bool boolValue) {
        // Determine which string to print depending if &#39;boolValue&#39; is evaluated as true or false
        const char* whichString = boolValue ? &quot;true&quot; : &quot;false&quot;;
        
        // Compute the length of the string we selected
        size_t len = strlen(whichString);
        
        memcpy(destBuffer, whichString, len);
    }
    
    int main()
    {
        // Locally construct an instance of our struct here on the stack. The bool member uninitializedBool is uninitialized.
        FStruct structInstance;
        
        // Output &quot;true&quot; or &quot;false&quot; to stdout
        Serialize(structInstance.uninitializedBool);
        return 0;
    }

The problem arises because of the optimizer: It was clever enough to deduce that the strings &quot;true&quot; and &quot;false&quot; only differs in length by 1. So instead of really calculating the length, it uses the value of the bool itself, which *should* technically be either 0 or 1, and goes like this:

    const size_t len = strlen(whichString); // original code
    const size_t len = 5 - boolValue;       // clang clever optimization

While this is &quot;clever&quot;, so to speak, my question is: **Does the C++ standard allow a compiler to assume a bool can only have an internal numerical representation of &#39;0&#39; or &#39;1&#39; and use it in such a way?**

Or is this a case of implementation-defined, in which case the implementation assumed that all its bools will only ever contain 0 or 1, and any other value is undefined behaviour territory?

Does the C++ standard allow for an uninitialized bool to crash a program?

The question is pretty clear. The following gives the reason why I think these expressions might yield undefined behavior. I would like to know whether my reasoning is right or wrong and why.

**Short read**:

(IEEE 754) `double` is not *Cpp17LessThanComparable* since `&lt;` is not a strict weak ordering relation due to `NaN`. Therefore, the *Requires* elements of `std::min&lt;double&gt;` and `std::max&lt;double&gt;` are violated.

**Long read**:

All references follow [n4800](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/n4800.pdf). Specifications of `std::min` and `std::max` are given in 24.7.8:
&gt; `template&lt;class T&gt; constexpr const T&amp; min(const T&amp; a, const T&amp; b);`  
`template&lt;class T&gt; constexpr const T&amp; max(const T&amp; a, const T&amp; b);`  
Requires: [...] type T shall be *Cpp17LessThanComparable* (Table 24).

Table 24 defines *Cpp17LessThanComparable* and says:
&gt; Requirement: `&lt;` is a strict weak ordering relation (24.7)

Section 24.7/4 defines *strict weak ordering*. In particular, for `&lt;` it states that &quot;if we define `equiv(a, b)` as `!(a &lt; b) &amp;&amp; !(b &lt; a)` then `equiv(a, b) &amp;&amp; equiv(b, c)` implies `equiv(a, c)`&quot;.

Now, according to IEEE 754 `equiv(0.0, NaN) == true`, `equiv(NaN, 1.0) == true` but `equiv(0.0, 1.0) == false` we conclude that `&lt;` is **not** a strict weak ordering. Therefore, (IEEE 754) `double` is **not** *Cpp17LessThanComparable* which is a violation of the *Requires* clause of `std::min` and `std::max`.

Finally, 15.5.4.11/1 says:
&gt; Violation of any preconditions specified in a function’s *Requires:* element results in undefined behavior [...].

**Update 1:**

The point of the question is not to argue that `std::min(0.0, 1.0)` is undefined and anything can happen when a program evaluates this expression. It returns `0.0`. Period. (I&#39;ve never doubted it.)

The point is to show a (possible) defect of the Standard. In a laudable  quest for precision, the Standard often uses mathematical terminology and weak strict ordering is only one example. In these occasions, mathematical precision and reasoning must go all the way.

Look, for instance, Wikipedia&#39;s definition of [strict weak ordering](https://en.wikipedia.org/wiki/Weak_ordering#Strict_weak_orderings). It contains four bullet points and every single one of them starts with &quot;For every x [...] in S...&quot;. None of them say &quot;For some values x in S that make sense for the algorithm&quot; (What algorithm?). In addition, the specification of `std::min` is clear in saying that &quot;`T` shall be *Cpp17LessThanComparable*&quot; which entails that `&lt;` is a strict weak ordering on `T`. Therefore, `T` plays the role of the set S in Wikipedia&#39;s page and the four bullet points must hold when values of `T` are considered in its entirety.

Obviously, NaNs are quite different beasts from other double values but they are *still* possible values. I do not see anything in the Standard (which is quite big, 1719 pages, and hence this question and the language-lawyer tag) that **mathematically** leads to the conclusion that `std::min` is fine with doubles provided that NaNs are not involved.

Actually, one can argue that NaNs are fine and other doubles are the issue! Indeed, recall that there&#39;s are several possible NaN double values (2^52 - 1 of them, each one carrying a different payload). Consider the set S containing all these values and one &quot;normal&quot; double, say, 42.0. In symbols, S = { 42.0, NaN_1, ..., NaN_n }. It turns out that `&lt;` is a strict weak ordering on S (the proof is left for the reader). Was this set of values that the C++ Committee had in mind when specifying `std::min` as in &quot;please, do not use any other value otherwise the strict weak ordering is broken and the behavior of `std::min` is undefined&quot;? I bet it wasn&#39;t but I would prefer to read this in the Standard than speculating what &quot;some values&quot; mean.

**Update 2:**

Contrast the declaration of `std::min` (above) with that of `clamp` 24.7.9:

&gt; `template&lt;class T&gt; 
constexpr const T&amp; clamp(const T&amp; v, const T&amp; lo, const T&amp; hi);`  
Requires: The value of `lo` shall be no greater than `hi`. For the first form, type
T shall be *Cpp17LessThanComparable* (Table 24).
[...]  
[Note : If `NaN` is avoided, T can be a floating-point type. — end note]

Here we clearly see something that says &quot;`std::clamp` is fine with doubles provided that NaNs are not involved.&quot; I was looking for the same type of sentence for `std::min`.

It&#39;s worth taking notice of the paragraph [structure.requirements]/8 that Barry has mentioned in his [post](https://stackoverflow.com/a/55211539/1137388). Apparently, this was added post-C++17 coming from [P0898R0](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0898r0.pdf)):
&gt; Required operations of any concept defined in this document need not be total functions; that is, some arguments to a required operation may result in the required semantics failing to be satisfied. [Example: The required `&lt;` operator of the *StrictTotallyOrdered* concept (17.5.4) does not meet the semantic requirements of that concept when operating on NaNs. — end example
] This does not affect whether a type satisfies the concept.

Which is a clear attempt to address the issue I&#39;m raising here but in the context of concepts (and as pointed out by Barry, *Cpp17LessThanComparable* is not a concept). In addition, IMHO this paragraph also lacks precision.


Content Type	Original Author	Original Content on Stackoverflow
Question	chqrlie	View Question on Stackoverflow
Solution 1 - C	too honest for this site	View Answer on Stackoverflow

Does sscanf("123456789123456789123456789", "%d", &n) have defined behavior?

C Problem Overview

C Solutions

Solution 1 - C

Logical OR for expected results in Jest

Set default header for every fetch() request

Attributions