pmeerw's blog

Feb 2024

Mon, 26 Feb 2024

constexpr string initialization fails to compile with _DEBUG

C++ code compiles with release build, fails with debug build (/D_DEBUG); MSVC obviously

Expectation: define _DEBUG (or switching between release and debug build) doesn’t change whether code is accepted; apparently Mircosoft has a different view...

// source code, x.cpp
#include <cstdio>
#include <string>

static constexpr std::string s = “asdf”;

int main() {
printf(“%s\n”, s.c_str());
Compile with debug:
cl /std:c++20 /D_DEBUG x.cpp
Microsoft ® C/C++ Optimizing Compiler Version 19.39.33520 for x64
Copyright © Microsoft Corporation. All rights reserved.

x.cpp(4): error C2131: expression did not evaluate to a constant
x.cpp(4): note: (sub-)object points to memory which was heap allocated during constant evaluation
Compile as release:
cl /std:c++20 x.cpp
Microsoft ® C/C++ Optimizing Compiler Version 19.39.33520 for x64
Copyright © Microsoft Corporation. All rights reserved.

Microsoft ® Incremental Linker Version 14.39.33520.0
Copyright © Microsoft Corporation. All rights reserved.


Bonus: when the initializer string “asdf” is longer, e.g. “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaasdf” also the release build fails (which is OK)

There's actually a very good and detailed technical explanation.

posted at: 10:00 | path: /programming | permanent link

Mon, 05 Feb 2024

Phishing awareness? Received from!

Does your organization ask to look for phishing cues as part of security awareness training?

Find misspelled domain names in the From: line, etc? (that can easily be faked)

It's pathetic to blame users for the phishing misery, which by and large stems from the IT industry's failure to deploy secure software and safe communication solutions.

Here's a more reliable and (easy) check of the email's "header lines" to see if the sender's email address matches the sending email server (SMTP server, specified in RFC 5321).

Look for the first Received: from line. Here's an abridged example ( is messaging

Received: from ( [IPv6:2607:f8b0:4864:20::32e])
    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
     key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
     client-signature RSA-PSS (2048 bits) client-digest SHA256)
    (Client CN "", Issuer "GTS CA 1D4" (not verified))
    by (Postfix) with ESMTPS id F1252E02CD
    for ; Tue,  5 Mar 2024 16:32:48 +0100 (CET)
Received: by with SMTP id 46e09a7af769-6e2b466d213so1283153a34.0
        for ; Tue, 05 Mar 2024 07:32:48 -0800 (PST)
MIME-Version: 1.0
From: Peter Meerwald-Stadler 
Date: Tue, 5 Mar 2024 16:32:36 +0100
Subject: bla
To: Peter Meerwald-Stadler 

So the SMTP server contacting's SMTP is Hence it's plausible that it's Gmail that is delivering an email (from a Gmail address). The "Received: from" line is put there by the receiving SMTP server, a trusted machine. On the other hand, the sender may put arbitrary things in the From: and To: lines, these values do not affect the delivery of the email and hence cannot be trusted.

Need to wait for some plausible spam/phishing email to have a more interesting example... :-)
Update (March 6, 2024): Didn't take long, here's an example using

Received: from ( [])
    by (Postfix) with ESMTP id C6A5FE0177
From: =?UTF-8?B?T1ZIY2xvdWQ=?=
Subject: =?UTF-8?B?Vm90cmUgbm9tIGRlIGRvbWFpbmU=?= "" =?UTF-8?B?ZXN0IHRlbXBvcmFpcmVtZW50IHN1c3BlbmR1?=
Message-ID: <>
I doubt ovhcloud sends their emails using ( []) and if they do I don't want to receive their sh*t anyway...

Email clients make it notoriously difficult to see this information (in Outlook it is hidded under ... / View / View Message details).

posted at: 22:00 | path: /rant | permanent link

Made with PyBlosxom