s/String discussion (again)

The question is what example code would you write that requires the use of strcpy, instead of the safer strlcpy.
Just increasing the buffer size for strcpy does not protect against crashes from other inputs.

Your definition of requires is likely different than mine.

If I know for sure I don’t need to do something then I don’t do it. I don’t understand what is hard to understand there.

With concatenation for example, testing for size beforehand will keep your initial string buffer clean and you just don’t concatenate and handle the issue. To me it’s better than calling the strlcat() function which tells you “hey man, I did what I could and messed up with your buffer but it’s not what you expected, i hope you are testing the result of this call”

I see the function set as tools in my tool bag, you use the tool that is suitable for the job.

I think @drmpf has a lot to contribute to the the newbie String community.
His String libraries appear to be maturing, and are fine for the low-level ‘duino users that only need 10% of their RAM & FLASH capacity.

Sure, c-strings require you to know what you’re doing, but the payoff is worth it in those cases that are heavy on RAM and performance.

I think the projects I’m working on which are using 65% of a 1284 Flash, and 85% of the RAM, I’d be a lot less inclined to use Strings.
I’m moving across to Pi for some of these projects, and with the memory and debugger capabilities, I’d certainly start looking at full String utilisation. .

So where is the example sketch?
I have never seen the checks you mention being include in forum responses.

I can appreciate that problem. I have an UNO sketch example that use most 100% of Flash (93%) and RAM (76%) and does not use SafeString (or String)

In those cases strlcpy/strlcat/snprint are good safe fall backs.

My argument with @J-M-L at the moment is that those are the methods that should be suggested to users as solutions (as opposed to strcpy etc) as they will keep the code running in the face of user stuff ups so they can get their debug messages printed.

Check again post #2 of this thread.. didn’t I say I agree on strlcpy()?

What I’m saying is that those l or n functions do not invalidate the historical functions. They do what they do with their limits which are clearly understood if you have been around for a while. What I am saying is if you are safely within the limits, then you can use those historical function and your code won’t crash... Eg if you test beforehand that a strcat() will be fine (to handle the exception before messing up with the buffer) then there is no reason to call strlcat afterwards which will do useless work…

PS: It’s a discussion, not an argument

I am saying they replace the historical functions, unless there is a reason not to use them.
I am asking for a sketch from you showing when you cannot use the newer/safer alternatives.
I lieu of that example sketch, strcpy/strcat/sprintf should be consigned to history and not appear in any new code.
As noted above Use of string char causes Arduino code to restart illustrates why they should not be used and why they should not be presented to forum users as the way to code text handling.

p.s. when I say 'argument' I meant 'arguing' a point of view. Nothing aggressive here :slight_smile:

The point is not about « can not use them ».

If you deal with a small nail, you don’t go grab the sledgehammer you use your brain and pick the right tool for the job.

What I’m saying is that they don’t replace them but are an extra tool to use when you don’t need the extra capability.

Say you have a large global buffer you reuse to build various URL with parametes. It would be OK by me to strcpy() the initial first part of the url (« http://server.com/project/dothis » or « http://server.com/project/dothat ») as you know for sure there is enough room For this text.

Then in a loop You would use strlcat() for adding your parameters for example esp. if there is unknown data length at compile time and check for proper behavior

But you could also check the available memory in the buffer before using strcat() if you don’t want to mess up the buffer content (add part of a parameter and have a complex fall back error management to get to the previous content) and decide to send a well formed (even if incomplete) request and then repeat for the remaining data (sending well formed chunked requests maximizing buffer size for example if you are in a fixed size packet based radio).

Why would you use strlcpy() for the first one or use strlcat() for the other ones if you check room beforehand to keep a well formed URL in the buffer besides following corporate coding guidelines?

There is no risk, it’s a function call doing the right thing and not premature optimization in my view. It’s the normal hammer, not the sledgehammer.

It’s fine if you see differently or if you make the coding rules in your company and just want to not have to deal with deeper code review at all for engineering cost reason and are fine with the additional small performance/resource penalty - but don’t make abusive generalization and say the code will crash if you do this. It won’t if you have your brain on when you code.

My point - when coding for small microcontrollers especially - is know your tools and use the right one for the task at hand but follow corporate rules if there is such a norm where you develop. (I’ve seen thriving environments with both approaches- those with strict code reviews and more freedom in coding tend to attract and retain better programmers)

PS: and because you are a smart programmer who knows its functions, you do that yourself in your library...

or is it "do as I say, not as I do" :slight_smile: :innocent:

@J-M-L Get back to me when you have finished 'hand waving' and have some real world sketches to discuss.

I guess you are out of argument….

This is not a philosophical discussion group. It is about 'real' code. When you get to that point we can continue.

It’s the bar category…

And meta level discussion is applicable to all sorts of code and situation. I gave you use cases. Can’t you handle abstraction?

Besides, What’s the value of posting code that work?

You have yet to post 'working' code for strcat.
Or a 'working' version of https://forum.arduino.cc/t/use-of-string-char-causes-arduino-code-to-restart/ that won't crash on un-expected input.
As I said get back to me when you start working in the real world.

and never make mistakes OR change the code later OR have to deal with input of unknown length.
You are driving without a seat belt there. No problems until you crash.

That's the beauty of libraries you write them once and debug them and then reuse them.
You are proposing rewriting and debugging continually.
Bound to get more errors that way.
Not a very productive approach, but if that's how you want to spend your time, you have more time them I do.
You will see from the SafeString code that is does A LOT of error checking that I would not want to rewrite every time.

You have made a lot of high level comments that hide the nitty detail -- still no example sketches to illustrate the code required.

of course. but that's using the sledgehammer all the time, even when you don't have to.

You are proposing rewriting and debugging continually

No I'm saying be careful and use the right tool when necessary.

still no example sketches to illustrate the code required

I don't get your insistance.

You did so in your library, I'm sure after careful consideration.. why didn't you call strlcpy() instead of strcpy() ? why did you use a char buffer instead of a String? ( :slight_smile: )

The point is not that saving those resources is always critical, the point is that doing unneeded work is a bad idea. Don't need it? don't do it.

I did not know they existed on Arduino :frowning:

The whole point of the library, to provide an alternative to String based on static char[ ]. Was that not obvious to you?

My objections to strcpy are based on a real life example of the crashes it causes.
Without example sketches your discussion is just all talk and opinion.
Not much use for OP's on this forum.

Kinda like a man who is his own lawyer has a fool for a client.


Wasn’t the smiley next to it obvious?

So you want to see questions about code properly written that does not crash?

Most of the string questions where code crashes are either abusing of the String class or have buffer overflow because OPs were careless or clueless. Using strlcpy() without testing the result for proper execution would have led to misbehavior in the code. If they had checked before, the would not need to use the l version. By posting their question, they gained useful knowledge. Learning from mistake is powerful.

And of course I don’t buy your explanation of why you used strcpy()…
remember you wrote

Start a new post when you have finished 'hand waving' and have some real sketches to discuss.

Yeah… that’s what people say when they don’t have any meaningful point to bring to the table.