Compilers removing security features: Optimization-unstable code

Coverity started scanning it in 2014, didn't they?
It's Free Software written by hobbyists, what do you expect, faggot?

It's just the foundation of all modern computing, no big deal.

A chain is as strong as it's weakest link. 0.00001% is too high of a risk. Why pour resources into technology on a foundation that is flawed to begin with?

are you a bot?

>hostile compiler breaks your code by applying optimizations that are completely nonsensical for the architecture the code was written for (or in the context of any architecture that has ever existed).
well yeah shame on me for writing code without predicting that, ten years from now, the compiler-writers would all be struck with meme-induced idiocy.

My code is perfect. Nothing I've written in 20 years has ever been hacked. Whenever you're at a hotel in the US, there are good odds your web traffic is going through the WAN optimizer I wrote. The release version has never even crashed. It's about 50k LoC of C++.

CISCO?

...

Or maybe you wrote shit that no one uses.

take a look at your metaphors. If the foundations of a building are flawed, and that becomes a problem, the building is trash. None of it can be saved.
If intel's backdoors are suddenly a huge problem tomorrow, 100% of my company's software investment in stuff that runs on intel can be saved. The 'foundation' can simply be replaced.

it was always allowed by the standard.
if you write for your own autistic interpretation of the C language and try to pretend it's valid C, that's your problem and not compiler writers.

Show the code, or it didn't happen.

Yeah, hotel internet is shit, but I guarantee you it gets use.

It's not public.

The current interpretation of the standard is one that nobody would ever have bothered writing a standard for, because the resulting language is complete shit.
'undefined behavior' is defined by the architecture. Which is largely defined by the machine. The nasal demon cult is wrong and stupid and they need to be kept away from compiler development.

ok, you just confirmed that your story is just a power fantasy.

Ok qt.

It's a huge problem right now. You just aren't seeing it because you and your company have nothing to say.

< Compilers including GCC will straight-up remove "security code"

It's not security code if it doesn't actually do what the programmer thinks. The article specifically mentions:
char * buf;unsigned int len;if (buf + len < buf)
GCC is allowed to ignore this because GCC targets machines for which this "security code" doesn't do what is expected of it. Interestingly, this code does work, on a 32 bit machine:
char * buf;unsigned int len;if ((unsigned int)buf + len < (unsigned int)buf)
because the standard does not allow the compiler to assume away overflow for unsigned comparisons.

wrong

as I wrote, it was shit from the start, because the standard always allowed that to happen.

Have fun learning about threads and the cache in your first year programming class.

A bunch of people earnestly wrote a standard for a practical language for practical programming, and the result was successful. But alas, a complete faggot made a joke about "nasal demons", and now language lawyers have twisted the practical standard into a license to break code. It's that simple. C's advantages in fact have been defeated by idiots, and as a result the language is becoming less and less practical, while gaining nothing.

The C standard always allowed arbitrary consequences when the UB is invoked.
The problem is in the standard (and therefore the language), and not in compilers.
These people decided to not amend the standard to make it more practical, and you're trying to blame compiler writers. This is silly.

link?

No. Compiler writers have not always been idiots. They gained idiocy over time. Although I keep mentioning the nasal demon meme, that's mainly in the people talking about it. The real pressures are probably a narrow focus on set benchmarks, C++'s avalanches of template fat, newfag members of the nasal demon cult who want to get "I added an optimization for hardware that doesn't exist to GCC" onto their resume, etc.

It was shit code that would fail depending on architecture anyway. There's no reason to enshrine code like that. If you think otherwise, then set -O0 and be happy and fuck off. The rest of us can handle it. The only one that is legitimately controversial is strict aliasing which is why several projects turn it off. You'd know this if you actually wrote code.

groups.google.com/forum/?hl=en#!msg/comp.std.c/ycpVKxTZkgw/S2hHdTbv4d8J
John F. Woods. Remember kids, your once-off witticism may just destroy civilization.

When the cianigger A.I is freaking out about compilers being backdoored, you know it's bad.

You can just compile rustc with rustc again. Then you are golden because you don't have the inherent (((optimizations for speed))) that llvm or gcc had.

Totally and 100% this. Compiler quality used to be ok. Now it's going the webdev route of shittyness.

oh gosh really? You mean some code written for one environment may fail if run on another? That only applies to NEARLY EVERYTHING ANYWAY. It requires immense amounts of effort for 'portable code' to actually 'be ported'. Portable C code is invariably filled with #ifdef hell for this reason. Because different environments are actually different in lots of ways. Hell 80% of my Perl would turn to shit if run on a bare Ubuntu box, because it's intended for CentOS boxes with cPanel lots of other specific environmental facts.
Idiotic compiler-writers are not helping this at all when they make your code fail even on the architecture that it was intended for.

Unlike I guess everything in Debian which runs on 10 architectures. But you're such a C pro that you must be right.

And if you wrote anything mildly interesting you'd have a journal of entries like "slowdown of 5% noted on new gcc version. using new -fplease-stop-hurting-me allows code to compile. Nothing we can do about this."
Years of that. Sometimes you can claw it back. But still something like 2.95 might still be the actual best version of gcc for you.

where?

no, they ported it. There's lots of expended effort there by lots of people. You are not serious.

The only thing I've ever had issues with performance-wise in gcc was vectored code, and we all gave up on getting the compiler to do that back in the '90s. Even today with significantly improved support for vectorization and even language features that have been added for it, you'll still see all the programmers capable of it resort to builtins so they know it will work exactly as they designed it across compilers.

No, the LLVM itself. Won't that still have this problem, or am I misunderstanding how targeting the LLVM works?

When you compile rust you must first use a standard C compiler like LLVM or GCC. After that you can just use rusts' compiler to compile it again.

The first time with gcc you get all of the bytecode/assembly that is unsafe and (((fast))). The second time you get all the rustc assembly/bytecode which is meant to gurentee memory safety. But there has been a reported bug in rust's memory safety that hasn't been fixed in 8 months. So it's probably a limited hangout for security. Use ada or pascel instead.

How about a personal example? I "ported" nearly 100k LoC of my C/C++ code to ARM (armel) by just compiling it on an ARM box back when a company with ARM boards was talking about acquiring us. I didn't change a single line of code and it ran just fine. It's all heavily bit-twiddling, too.
It was using Debian as a base in both cases which made it quite easy. Just don't write shit code and you won't have problems porting it.

user is talking about optimizations done at the IR->Machine code stage, after rustc has done its part.

I believe you. You probably didn't even change bit-widths. You're operating on a level where that's practically the same architecture, where other people have already done all the hard work of closing gaps. Example: ARM doesn't even have integer division? Don't worry a library implementing that was linked in for you. Similarly, my Perl that wouldn't even make sense under Ubuntu would run fine on ARM provided that CentOS and cPanel were first running comfortably there.
The modern world is pretty comfy. A few CPUs won. A few FPs representations won. One's-complement is spoken of only like Jews speak of otherwise-forgotten enemies. Pretty easy to say you're OK with hostile compiler-writers when they have historically minimal opportunity to fuck with you.

wat
If you mean word length, going from 32 to 64 did require a couple changes due to typedefs not existing for some of it back when I wrote it (structs passed to setsockopt and netlink, which Linux is /way/ better about these days) but it only took me a couple minutes.
This is no surprise to someone who isn't new as fuck. I'm old enough to remember having to /manually/ call PAL code for it. But as I'm in networking we do all sorts of things to avoid integer division anyway as it's slow. I bet Holla Forums would be horrified, actually - in cases where we need to divide by 1,000,000 we use shift-based approximations instead. The error in the result actually causes small hiccups in Linux's TCP stack if you're being super anal about it.

Triggered

I was thinking more of going from x86_64, say with something as petty as 64-bit constants using an int as an array of booleans, to 32-bit ARM.
(One thing I did learn from ARM is that with a divisor known at compile-time you can use multiplication instead of division. Wild.)

It's not a problem as we don't use int for bitflags, we use either stdint's like uint32_t for userland or Linux's u32 in kernel. I've not seen a 64 bit bitflag variable before, but they'd port fine to 32 bit as that's trivial for the compiler. I track time as nanoseconds since 1970 in a 64 bit variable even on 32 bit architectures as it's still faster than using the split representations like timeval.

Hey OP, you're late to the party, we've had the SecureZeroMemory function for years. Do you know why the plain ZeroMemory wasn't good enough?

msdn.microsoft.com/en-us/library/windows/desktop/aa366877(v=vs.85).aspx

... how did MS fuck that up so badly?

You need an 8-bit computer fam, no modern thing is trustworthy.

C++ on Windows is a disaster. It's why Windows programmers use C#.

where is microsofts fuckup exactly?

A function that exists to zero memory that doesn't necessarily zero memory. It doesn't do what it claims to do.

how is it microsofts fault when a compilere decides to optimize your code?
en.cppreference.com/w/c/string/byte/memset

If the function states it does something that it does not do it is a bug. I can hand memset() a volatile and it does exactly what I expect.

but how is that microsofts fault though? it is the compiler that otpimizes it away

It's Microsoft's compiler.

what is microsofts compiler? gcc? clang?

Get checked for autism, user.

i dont understand. you said that it was microsofts fault that compilers optimize a function call away. im just asking you to elaborate on that.

From FreeBSD's man page:
The explicit_bzero() variant behaves the same, but will not be removed by a compiler's dead store optimization pass, making it useful for clearing sensitive memory such as a password.
OpenBSD has done this for a while now, and guess how they do it on Windows?
with this SecureZeroMemory function
github.com/libressl-portable/portable/blob/8b80bcdad82a57d195381a150aa2690f188b127e/crypto/compat/explicit_bzero_win.c

WHAT COMPLETE AND UTTER BULLSHIT. You're thinking of leaving things as implementation-defined or implementation-dependent. Undefined behaviour is the language makers being lazy retarded retards.

Also this thread is a stealth rustfaggot thread. Why aren't we banning those pieces of filth yet?

Storing sensitive data like that on the heap is retarded, anyway. Who knows what happens to it - it could even get swapped to disk. You should map your own page and protect it, then unmap it when done. Hacking the language or compiler to force it to deal with things that are out of scope is idiocy. Any code that contains explicit_bzero() is announcing it is broken.

The point is to zero the memory out as soon as it's no longer needed. That's relevant also with memory that isn't dynamically allocated.
Why is the compiler removing code, ever? Why do you think this particular 'optimization' even exists? Someone has already forced the compiler to engage in matters outside its scope.

why though? rust is technology. why dont you fuck off and make your own board?

if you are so autistic that you cant bear the thought of having a compiler optimize your code, have you considered turning off optimizations or not using a compiler at all?

Rust is a cult where members pretend to care about security while actually ignoring it and engaging in webdevshit SJWism instead.

You don't understand. You should never place memory that has special requirements in any language-managed memory location; heap, stack, whatever. Placing it on the stack is unfuckingbelieviably retarded so we'd be talking about programmers with at least half a clue thinking they need to allocate it separately on heap and explict_bzero() to keep it from spreading. That's still completely wrong and needs to be done using mmap() and mprotect(). You'll notice this being done in gnupg and gnutls and likely many others. It's been the standard way of dealing with this since the '90s.
Go back to webdev, user. The compiler can do whatever the fuck it wants as long as it doesn't violate any property of the language, and we want it to do that. We want it to figure out the most efficient way to execute our code. But if your code depends on what happens under the hood YOU are wrong.

This problem would have never been an issue if programmers had switched to Ada/SPARK decades ago. What are ranges and subtypes? What is automated range checking? What are contracts?

Jesus you cultists are just sick. Absolutely sick in the head. The compiler said "I don't *think* those writes to memory do anything, even though memory is externally observable, so I'm going to throw them away even though the programmer wrote it that way. I'm doing this because I am helping."
Nobody ever set out to create a programming language that made it easy to leak passwords because it had compilers that applied optimizations based on a memory model ("nobody can tell if this happens or not") that is a lie. The whole reason C became popular at all is because it had a weak model that effectively let you work with the system as it is.
Just use Java and stop breaking other languages.

I like behavior-preserving code transformations. I'm comfortable with a compiler 'breaking' code by changing its performance characteristics, provided that the result is consistently improved. Since there's a tension there - using lots of memory for a small performance increase may actually harm performance - I expect compilers to have switches to resolve that tension, and they do. Where's the "fuck off with changing the behavior of my program" switch? Just because you're two years old and think C is the only non-scripting programming language doesn't mean that this shit is inherent to optimizing compilers.

I'm hearing an awful lot of complaining about compilers merely doing their job. They apply optimizations that are allowed according to the language specification. You don't like the undefined behaviour? Go lynch the guys who made C. They deserve it.

The story of C:
akchutaly, this is C. Everyone doing it before was just not doing it as well as these new guys are.

Why is the acceptance rate for SparkAda so low anyways? It's open source now isn't it?

wew

Not really, the only way that works is:
memset(ptr, 0, len);
asm volatile("" : : "r"(ptr) : "memory");
All the other things are either non-portable or simply not working under certain conditions (like LTO)

If you are not "smart enough" to write C then you got what you deserved for writing security shit at your level.

How did that joke change the way people write compilers?

lol c was never fine take those rose tinted hacker glasses off faggot

Oh no, the main problem is you can utterly fuck up an entire system with the non-toy equivalent of fizzbuzzes. C just makes it too easy to make mistakes.

I know you are all embedded developers with a thousand security certifications for your programs that were programmed in one sitting, worked flawlessly on the first compilation, and didn't require static analyzers nor extensive testing, but 90% of the programs in your computer are done by inferior webdev-tier (protip: you are not webdev-tier, because you are perfect) developers in C, and as long as one of your programs is vulnerable, you are vulnerable. C should be used LESS than it is now, no excuses.

Which language should be used more?

With the current options? Ada.

have you considered haskell??????

Yes. Considered it and discarded it after having intractable memory usage issues. Yes, even with strictifying things.

...

FUD, FUD and more FUD, with a side order of C/C++ being thoroughly established. The proverbial rockstar hacker doesn't like being told what tools to use. Observe: wiki.c2.com/?AdaLanguage

Write ur own macro assembler in machine code, toggled-in at the front-panel or ROM monitor (if ur machine doesn't have this, it sux and ur a lamer)

wow, the rust shills are growing more subtle.

Anything but hand written C/C++.

More subtle and more desperate. They know their crap is never going to catch on outside of silicon valley webdevshit where SJWism is rampant.

Let's take this for example. Let's say you have memory maped IO and at address 0x1234ABCD you have some register. Now you do this.
*(uint32_t*)(0x1234ABCD) = 10;
*(uint32_t*)(0x1234ABCD) = 20;

To a compiler it looks like you're just writing value 10 and 20 to the same address, so it will drop the first expression. That's good, if you don't want that, you use volatile. That's it.

So hand written Java?

Depends on what you wanna do, but yeah, unless your program requires really low latency times.

Even trivial Java programs take significantly more memory/cpu than the equivalent C++ one.
Advocating Java got us into the mess we are in today with all the jobs being outsourced to know-nothing pajeets who produce software that's bad even for Java standards.

GCC isn't a compiler. It's a collection of compilers, that's even in the name.
Don't use that optimization in your code then. You do know you aren't forced to pass -Ofast every time you compile right?
What part of "undefined" you don't understand? If you rely on undefined behaviour it's your problem to make sure it still works in future versions of the compiler.
5 shekels have been credited to your account.

Yep, that has been a solved problem since forever. Just tell the compiler the "dumb" code is there for a reason and it'll work. Without that the compiler would miss many optimization opportunities just on the off chance memory writes have to occur in order.

I'd rather run a thousand bloated programs than a single sleek program made by developers who didn't receive the memo that strcpy is evil, thank you.

Turn off your computer = security problem solved.

Any x86 CPU sine the Pentium MMX will have the additional 64-bit MMX registers: this makes 64 bit ints pretty easy to do on 32 bit machines since 1997

Is this supposed to be a bad thing? 1960s PL/I is still better than a lot of languages today, especially if you're comparing it to C.

bitsavers.org/pdf/ibm/360/pli/C28-6571-3_PL_I_Language_Specifications_Jul66.pdf

Those aren't general purpose registers and aren't usable for what you're thinking. The 386's FPU also had 64 bit registers that weren't general purpose.
But simulating 64 bit addition and subtraction is trivial, and optimized code avoids division, anyway.

...

C strings are frequently used in C++. C++ strings are very limited and could be called a mistake.

For the purposes of my education do you mind explaining why you think C++ strings are limited and a mistake?

While using straight C for user programs I've conditioned myself to absolutely hate char arrays. You will not think they are a problem until someone convinces you to translate your program in their language, then the nightmare of malloc'ing and strcpy'ing char's begins. While std::string does concatenation and .... why the fuck do I explain this shit to you. Just answer my question thanks.

- A C string at any position in the string is also a C string. A C++ string turns into a C string when you do that. No one wants to deal with the bullshit of having to pass an offset to every function taking a C++ string (not even the C++ spec) so what this usually means in practice is people are either dynamically allocating substrings (awful) or converting C++ strings to C strings which complicates everything unnecessarily (why use a C++ string at all?). A language spec with Pascal strings should have support for fast substrings but C++ somehow fucked that up. The way memory is handled internally isn't even well-defined so they might even be reference counted under the hood.
- C++ strings are not 1:1 with buffers. A network buffer is also a C string as long as you ensure you've added a null. To use data you read from a file/network/etc. as a C++ string it requires pointlessly allocating and copying the data due to the shitty language design. Strangely, strstream used to be part of C++ and made some of this work without copies then they 'deprecated' it in favor of stringstream which forces allocating and copying. I blame the Jews. Similarly, C++ strings require initialization in .ctors even if they're static.
- C++ strings in real code that manipulates them with C++ functions have ridiculously bad performance due to the implementation of stringbuf. imo it's the biggest mistake in C++ that is specific to C++. Those per-character functions are virtual and cannot be optimized away by the compiler. There are many situations where your code will literally be calling a virtual function per character. C++ programmers usually run into this first when they try to figure out why cout is so incredibly slow compared to printf despite not having to parse a string for format characters (novice C++ programmers expect it to be faster).
- C++ strings did some things in a bloated way to support unicode yet are useless for it. Sure, you can abuse them as utf8, but then you're using them like a C string. Have you ever seen someone instantiate a C++ string as anything other than char? They were supposed to be usable with wchar_t but that was possibly the biggest mistake in all of C/C++ (a large portion of the language spec deals with wide chars but all of it goes completely unused because it's fundamentally broken) and today everyone uses ICU strings instead to get around the limitations. But you're still stuck with the explicit instantiations in libstdc++.

I do maintenance on a code base that was originally C, and we've been dragging it, kicking and screaming, into C++. As part of this, we run HP Fortify (more like Shitify) on the code base. Take this code:
char name [16];strcpy(name, "none");
Fortify, and faggots like you, complain that there's a strcpy. It is trivially discernible by someone not mentally retarded that this is an unconditionally safe use of strcpy (and most retards could figure it out with a little direction). And now I have to remove it because "strcpy isn't safe".

You've got that backwards. You wrote impossible code, the compiler accounts for that. Not GCC's fault that you muted the warnings telling you your code's fucking retarded.

great, it's just FUD rust shilling
move along nerds

Maybe they should start using std::string_view?
en.cppreference.com/w/cpp/string/basic_string_view

? C++ strings are required to store null-terminated strings under the hood since C++11.

Just pass your_string.c_str() and your_string.size() to whatever function expects some buffer.

Not sure why you mention that; that has nothing to do with std::string and everything to do with iostreams, which are one of the oldest and crappiest parts of the standard library. You can still use printf if you want to:
std::string your_string = "nigger";std::printf("%s", your_string.c_str());

std::string_view doesn't fix the problem with std::string, it provides an alternative in a specific case. All the existing C++ code that only takes std::string won't work with it, and future C++ code will be shittier having to plan for it (do you create a worthless temporary so you can handle std::string, do you template it and move the whole function to the header, or do you make a duplicate function? These are your only choices). It's trying to fix a trainwreck by slamming another train into it. A better idea would have been to create a std::string2 or whatever that deprecates std::string and adds the missing Pascal functionality and solves a lot of other otherwise unsolvable problems with it.
What do nulls have to do with reference counting? That's not even remotely the same issue.
... user, HOW do you get data you just read from the network into "your_string"? By pointlessly allocating and copying, like I said. Are you even reading?
As I said, "C++ strings in real code that manipulates them with C++ functions". Good luck doing much with a C++ string without touching streambuf.
No you cannot. C++ strings can contain embedded nulls, base types other than char, etc.. If you want to support real C++ strings you have to use real C++ functions and then you're stuck with the issues I mentioned.

I have a feeling that your std::string2 wouldn't be any more backward-compatible.
If you can't template it and you don't need a copy, then you should make a single function that takes only string_view, which can be implicitly constructed/converted from both C strings and std::string.
I'm just curious about how you would implement std::string with reference counting given that every copy of a string must have its own unique null-terminated char buffer.
Depends on how your function that reads from the network works. Does it take a pointer to a buffer and fills it up? if so, then you just pass it your_string.c_str(). Otherwise, please clarify.
Are you referring to stuff like stringstream? You can do much without that.
So? Don't embed a null in a C++ string, just like you wouldn't embed a null in a C string.
If it's std::string (and not some other std::basic_string), then it's char and only char.

No. There are no strings in C. What you are saying is that a pointer to random ass memory that you hope contains character data is still a pointer to random ass memory that you hope contains character data when you add a retarded offset to it.

Only if you are a fucking idiot. A coworker wrote some code that const_casts the result of .c_str(), so that he could pass it to a function that modifies the underlying data. I can't wait until we compile that where string is reference counted under the hood.

Do you have any real metrics that this is the source of performance issues in a program?

As far as I can tell, your problem with C++ strings is that they don't allow you to be a C programmer with them, coupled with a misguided belief that you can write more optimal code than the compiler can optimize naive code.

Considering that .data() returns a non-const pointer to the array in C++17, I doubt that any modern implementation uses reference counting.

Small strings are also statically allocated inside the std::string because of the small string optimization used in libstdc++, libc++, and MSVC's C++ standard library. I'd imagine other C++ standard library implementations would use SSO as well.

True. Also, now that I look into it, C++11 makes it hard to have a reference counting std::string because accessing it is not allowed to invalidate references to its content (which copy-on-write can possibly do).

Gee, no kidding. Was saying 'deprecate' a hint? But it would allow solving problems that string_view will only make worse.
That's the "create a worthless temporary" option I gave. This is why C programmers make fun of C++ programmers, that this is considered an acceptable solution.
You could look at the existing STL implementations where it is reference counted. There are a whole lot of crazy std::strings out there with all sorts of different algorithmic complexities which makes it impossible to use portably with good performance. Depending on your gcc version, your basic_string might be vanilla, refcounted, or using a short string optimization. gcc 6 still has their refcounted one in the header although they use a different version if you enable C++11; grep for "_M_refcount".
That isn't true. They don't need to be unique.
You seem unaware that c_str() is const. Even if you rely on a guarantee that a std::string is contiguous (which means you code is no longer compatible with C++98 code), you still can't pass a plain memory buffer as a std::string without an allocation and a copy. If 'network' is confusing you, think of it this way, can you mmap() a file and immediately pass that to a function taking a std::string like you could a char *? What about a buffer received from setsockopt()? No. But a function dealing with C strings will have no problem with it. This is one of the problems they tried to solve with string_view and in typical C++ fashion fucked up.
Demonstrate the C++ equivalent of sprintf without using anything that touches streambuf or has horrible performance problems (hint: why do languages have things like StringBuilder, StringMaker, stringstream, etc.?)
That's some Pajeet-tier thinking, "it's not a problem as long as you ignore the requirements". Your code can be passed valid C++ strings with embedded nulls or multibyte characters and your code can't just choose to fail.
One doesn't (hopefully) write a templated function that takes std::string, you're supposed to take basic_string in templates. Otherwise, you break all the other (worthless) C++ strings and user-derived strings. If you're going to reject most of C++'s string support, just reject all of it.

There's no allocation at all with string_view. Is your problem that string_view contains a pointer + a length instead of just a pointer?
You really should enable the latest version of C++. As mentioned here: , gcc's old reference counting implementation is no longer compliant.
You're right, I should have said .data() (with C++17).
I'm okay with this.
Ok, I get what your problem is: const string& parameters forcing a copy of the buffer. This can be solved by replacing every such parameter with a string_view.
Not standard (yet), but there's this: github.com/fmtlib/fmt
If you're making a function that other people will call, then you can just require that the std::strings that they pass don't contain '\0'.
If you control the whole program, then you can prevent that situation from arising in the first place.
I take it that every time you make a function in C that takes a const char*, you also make other versions that take const wchar_t*, const char16_t* and const char32_t* (which are defined in the C standard library)?
I don't "break" them, I just don't support them.

You are literally four keystrokes away from a compliant version, bitch.

As I mentioned, I'm fully aware that most C++ programmers don't see the creation of a worthless temporary as a problem. But C programmers see you putting a struct on stack, initializing several fields, then passing a pointer to that struct purely to work around the awkwardness of your language and not any sort of programming problem as an example of why C++ is shit.
It must be nice to not work on anything of any importance where compatibility matters.
Again, I don't see string_view as viable due to the reasons I listed earlier. I primarily write C++ code and we gave up on C++ strings a long time ago.
This isn't really "C++ strings". It also has horrible performance problems, at least as of a year or two ago, and suffered from the variadic template explosion problem you might have seen me mention in other threads if you're a Holla Forums regular. The concept isn't bad though, and I have my own implementation that performs closer to the better mprintfs.
This is pure streetshitting. You're adding restrictions purely because you have a problem using your tools, not because the restrictions were desired. Don't do this.
No, as no one uses any of the wide character support in C. That's different in C++ where people expect to abuse standard library containers for their own types. You should never use wide character support in C++ either, though.

That's bad code, it's right to remove it. The problem is you have two statements that have an invisible requirement between them yet could appear at any distance from one another in a program. It's very fragile and is just a matter of time until some programmer making a change converts safe code into unsafe code. In your case, it often happens during localization - some programmer changes "none" to _("none") and then some translator triggers the bug in a language where a name of none is translated as a phase.
snprintf() would be fine in that situation as it would fail gracefully. Hopefully there's not a policy where you work to not use it. Never use strncpy() or strlcpy(), though.

What's wrong with strlcpy?

It's not standardized and on many platforms will have no maintainer. You can get the same behavior from snprintf, standardized.

Microsoft have their own compiler, MSVC Compiler, they are the ones who ultimately programmed the compiler to optimize the code. It doesn't matter what balances you make, the fact is Microsoft caused the problem.

The bigger faggots are the ones who think strncpy automatically makes everything safe.

What? You're supposed to pass string_view by copy. It's no more costly (and slightly less error-prone) than separately passing pointer and size arguments. Having a parameter that's a pointer/reference to a string_view would be pointless.
Since C++98 code can't assume std::string is contiguous, it should be possible to add code which does assume that and just compile with a C++11 compiler. Unless what you want is actually some kind of retrofitted forward compatibility, which pretty damn retarded.
Your reasoning is weak.
No, but it's a C++ replacement for sprintf, as you ask. And one that has been proposed for addition into the standard library.
No, not really: github.com/fmtlib/fmt#benchmarks
Absolutely not. The variadic template function is just a thin wrapper (easily inlined); the arguments get stored in a type-erased container.
I can't believe a C programmer would be uncomfortable with the idea of a function requiring the caller to enforce restrictions on data passed to it. And the "don't put null terminators in the middle of the string" restriction should make you feel at home, too :^)

so what you are saying is that gcc and clang dont optimize away ZeroMemory?
do you know about memset_s? is this also microsofts fault?

They also optimize it. Blame society if you want, Microsoft is the one to make it and say ok.

Pajeet, maybe you should try it. There is extra cost of using a std::string_view to accept a std::string - a worthless temporary and an additional level of dereferencing. Again, this is why people make fun of C++ programmers. They have a total lack of awareness of all the bloat their language is generating under the hood.
So, again, going back to the three ways I said you'd be stuck with solving this, you either have a useless temporary created (bloat, as seen below), you have to make full templates out of functions that might have not been templated before (horrible), or make duplicate functions to accept string_view and string (horrible).
std::string_view makes a mess out of the problem they're trying to solve by forcing this on C++ programmers if they want to try to solve the problem of std::string being designed poorly. A better solution would have been to redesign it as std::string2 like I mentioned. But C++ hates better solutions.

#include #include extern void fooView(std::experimental::string_view const &);extern void fooString(std::string const &);void fooViewCall(std::string const &s) { fooView(s);}void fooStringCall(std::string const &s) { fooString(s);}

Disassembly of section .text:0000000000000000 : 0: 48 89 f8 mov %rdi,%rax 3: 48 83 ec 08 sub $0x8,%rsp 7: 48 8b 7f 08 mov 0x8(%rdi),%rdi b: 48 8b 30 mov (%rax),%rsi e: e8 00 00 00 00 callq 13 13: 48 83 c4 08 add $0x8,%rsp 17: c3 retq 18: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 1f: 000000000000000020 : 20: e9 00 00 00 00 jmpq 25

The thing about variadic templates is they work great until they don't. I've personally seen that with fmt which is why I wrote my own. The compiler has a tremendous amount of leeway with them and there is no way to instruct the compiler to not be stupid (other than non-portable ways). There's a better way now using parameter packs that keeps the compiler from randomly fucking everything up but I won't be able to use that for some years as everything I work on is still on C++11 or below.
They're much trickier than you think. Hint: is the template recursion depth unlimited? What happens when the limit is reached? Is it standardized?
I'm actually primarily a C++ programmer.

Err, the code that disassembly is for is this, not the above,

#include #include extern void fooView(std::experimental::string_view);extern void fooString(std::string const &);void fooViewCall(std::string const &s) { fooView(s);}void fooStringCall(std::string const &s) { fooString(s);}

ok but how is it microsofts fault then?

gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,source:'#include #include /string_view> extern void fooView(std::experimental::string_view); extern void fooString(std::string const &); void fooViewCall(std::string const &s) { fooView(s); } void fooStringCall(std::string const &s) { fooString(s); }'),l:'5',n:'0',o:'C++ source #1',t:'0')),k:50,l:'4',n:'0',o:,s:0,t:'0'),(g:!((h:compiler,i:(compiler:g72,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',trim:'0'),libs:!(),options:'-O3',source:1),l:'5',n:'0',o:'x86-64 gcc 7.2 (Editor #1, Compiler #1)',t:'0')),k:50,l:'4',n:'0',o:,s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4

The compiler's behavior is the result of Microsoft's actions.

yes. but where did microsoft do anything wrong?

These fucking shills get more sneaky as well as more desperate. FUCK OFF, man.

The issue is they made ZeroMemory a macro. The body of ZeroMemory is copied into where ZeroMemory is used which provides the compiler enough information to go "You don't do anything else with this after writing to it, so I can safely fuck this code off" which is perfectly fine according to the standard since the standard (rightfully) makes no assumptions about the environment in which the code is run. If you wanted to not have the code eliminated, then you would make the pointed to value volatile which the standard does make a statement about, which is "This value is modified outside the scope of what you can see, don't make assumptions about it."

How about that, discussing actual technology on the technology board! This thread isn't politics of technology companies that are completely irrelevant to technology, it's actual technology!

yes. zeromemory is meant to go fast. securezeromemory is meant to ensure that no compiler optimizes it away.
but where did microsoft do anything wrong?

godbolt.org/g/s27WUz

In the trash it goes.

You do realize that the definition of fault can go two ways and that an undesirable action can take many forms?

i dont understand what you are saying. can you please specify what microsoft did wrong?

Microsoft didn't do anything wrong, I was just interpreting fault as a figure of speech which translates to a result.

Rust is designed to go into the trash.

rust passes

I've audited hundreds of instances of strcpy, and it is not worth my time to replace all of them.

In the unlikely event that we ever internationalize the code, the i18n team will have to be cognizant of it. Yes, we're leaving something for them to fuck up, but if they fuck it up, they didn't do a good job anyway.

< C programmers see you putting a struct on stack, initializing several fields, then passing a pointer to that struct purely to work around the awkwardness of your language and not any sort of programming problem as an example of why C++ is shit
And I have seen "Expert C Programmers" fuck up memory management so many fucking times that all of that overhead to prevent Entitled Cunt Boomer's from fucking up the memory management again is worth it. The only "programming problem" that we're trying to solve is the chasm between the size of the ego of people like you and your actual programming abilities.

No one in our shop thinks of std::string as a standard library container. No one uses it for anything but char. Then again, most of them should probably never stopped programming in Java.

All that said: in the rare events when I write network code, it's C strings internally, with those obnoxious std::string temporaries being returned.

The programming problem that std::strings solve is the complexity of the code. Specifically, they relieve the programmer of concerns of the lifetime of the memory. For the same reason, I use shared_ptr for things that will never, ever be shared. I as the programmer can focus on the problem at hand and inefficient magic in the background handles the parts of the problem that I can't be assed to keep track of: the lifetime of the objects I create to solve said problem. Just as it isn't worth my time to replace copies of strcpy with strncpy, it is not worth my time to keep track of the lifetime of a C string (which many of my pajeet-teir coworkers would just fuck up anyway). The fact is that C++ was designed to solve problems where memory micro-management is hindrance to productivity: things that you think of as important get in the programmer's way of solving problems that are so complex that the average programmer can barely mentally handle them.

Post links some of your projects, and we'll see about that

Linking my company to a watering hole for Nazi pedophiles? What could possibly go wrong?

Well they got trump elected, so worst case scenario you save large amounts of advertising shekels and your website goes down due to overload of people accessing it. Don't you know major (((brands))) advertise in memes here? I've seen a snicker's candybar advertisement a few times now and the challenger car advertisements.

Also the pedophiles are cianiggers and ghcq faggots spamming the stuff. Most of Holla Forums is heavily against pedophilia. The few that aren't are kikes.

NON-PRACTICING
NO JEW NO GAS
NON-PRACTICE
YES LOLI NO TOUCH

A good programmer internationalizing that would realize the strcpy() is dangerous and replace it. But you already were told that by a code quality tool. So that programmer while wasting their time fixing bad code will be thinking, "what retard left this here?" and that retard will be you.