Technorama

Drones should have mandatory transponders and GPS in control packets from controler. Likewise controller should also broadcast GPS position in signals, giving law enforcement an accurate record of the positions

Likewise, if using a SIM card, easy to track
Otherwise, follow it with another drone

Pretty easy to use a trained eagle to take out a drone too

Alternatively, police could use drones or radio controlled model planes with loose string nets and fly into the drone.

the following code gives an error, but actually we all know we want the strings in the regular std::string container, why can't C++ language be updated to resolve this issue?

The fix is to allow dynamic creation of const strings, in this case case a const char [13] containing "hello world", which can then be assigned to the string

//g++ -Wall -o str str.cpp
#include
using namespace std;
int main()
{
    string s = "hello " + "world";
    return 0;
}

$ g++ -Wall -o str str.cpp
str.cpp: In function ‘int main()’:
str.cpp:6:25: error: invalid operands of types ‘const char [7]’ and ‘const char [6]’ to binary ‘operator+’
     string s = "hello " + "world";
                ~~~~~~~~~^~~~~~~~~
Even as this it fails:
string s("hello " + "world");


//g++ -Wall -o str str.cpp
#include
using namespace std;
int main()
{
    string s = "hello " + "world";
    return 0;
}

Never use strlcpy from OpenBSD project, it is dangerous and should be deprecated. It trashes buffers and leaves them modified.

strlcpy is terrible, it breaks ISO TR24731 "Do not unexpectedly truncate strings" by overwriting memory before checking there was enough space to copy all the bytes.

Also strlcpy doesn't satisfy ISO 26262 Functional Safety Standard
http://www.ni.com/white-paper/13647/en/

Some easy golden rules.
1. Don't leave a buffer partially modified, if you don't know you you have space, don't update it. Check size first (even prepare the strcat, and then based on that length, if space, actually move it to the dest buffer.
2. Always terminate strings with the NUL byte (this is a defect in strncpy spec)

The security risk is that crucial data is damaged (loss of data), that change and causes software to behave in an unexpected way, if the software is vulnerable - then it is a risk. This is the reason it is better to not damage/corrupt any data in memory by strlcpy.


Quoting this lwn article "The essence of the argument against strlcpy() is that it fixes one problem—sometimes failing to terminate dst in the case of strncpy(), buffer overruns in the case of strcpy()—while leaving another: the loss of data that occurs when the string copied from src to dst is truncated because it exceeds size."

Greg has a similar article

Jake article

Kees article

Brought this up with Theo de Raadt, ego felt too big

Dr Dobbs

So we're back to using strncpy() and manually adding the terminating NUL byte after each use to ensure no overruns.

Alternatively, use the C11 Annex K "safe C" functions, which sadly have not been added to Glibc yet. C11 ISO/IEC 9899:2011  N1967. Fortunately Open Watcom  does support.

C18 also contains Annex K, so hopefully will be widespread soon.

I like the way it bounds checks both buffers:

errno_t strncpy_s(char * s1, rsize_t s1max, const char * s2, rsize_t n);

Personally I would rather it return EFAULT if s1 or s2 point to NULL (nullptr in C++). At least it is always certain it always NUL terminated.

Unfortunately Microsoft implementation allows n to be set to _TRUNCATE, I don't support this. Better to remove all truncation behaviour from strncpy_s. (strcat_s doesn't truncate).

Also, don't use strcpy_s, better to know the number of chars in the source buffer to check before modifying.

I can see why coders use std::string now. There isn't industry consensus on how to fix C strings.