s/String discussion (again)

I think you have the process around the wrong way. You want the all the posters to lean the cstring basics first.
That is not the way the Arduino Language is presented.

If the OP wants to learn low level C string methods, I am sure he will get lots of assistance here.

But most of posts I see, just want to get something running and don't care about our stands on the pros and cons cstring/String or low level code versus pre-tested libraries.

So I will continue to recommend the easiest and safest alternatives, be that strlcpy, SafeString or String as appropriate, that solve the OP's problem at hand, and let you worry about the OP's education.

I agree with strlcpy() that's positive :slight_smile:

just want to get something running

sure, but if we can get them to use their brain along the way, we ought to try that first...

Sure, but it should be along the lines of "strcpy/strcat/sprintf are terrible functions that are very prone to generating runtime errors, here are three much safer alternatives for text handling"

you learn from errors.

Knowing strcpy/strcat/sprintf exist is good for performance when you know what you do and knowing there are alternatives with protection (at the cost of performance) is also great.

In both cases you need to check (before or after) that the operation was fine anyway... so I don't see much of a difference if you want to write reliable code handling exceptional cases

The difference is between your sketch crashing or not.
And when was the last time you saw any code on this forum that checked strcpy/strcat/sprintf before or after?

not if you check first you have enough room (or you know you have enough and thus don't need to check)

usually there is enough room (unless there isn't :wink: and that's why the question comes up).
it's a teaching opportunity.

Not obvious for strcat, in general. If you do code it you end up with strlcat so just use that to start with. The teaching opportunity is just don't use these methods.
I would add strdup() as well.
And you won't convince me on the performance argument until you have code that runs and is bench marked using the safer alternatives and is shown to be too slow.

the point is not the general case. it's when to use the right tool for the job and the constraints. having the necessary Knowledge helps.

if you know that

  • you don't need the check (it happens)
  • every microsecond counts
  • every byte of SRAM counts

then you'd be happy to have options..

The discussion can also be different if you code for a Mac or PC or smartphone with virtual memory, an OS with garbage collection and GHz clock rates...

Knowledge is power.


we have polluted this thread enough. let's agree we have a different opinion on this.

You don't 'know' that until you do the bench marks. You know the quote about premature optimization, it was coined when computers were 'small' so it still applies here.
You keep avoiding the issue around strcat as though that will somehow make it go away and what about strdup(), that is a standard C function for copying strings. Are you proposing posters use that to make a copy of their string input for parsing?
Edit - I have requested these comments be moved to another topic

strdup() is not a standard C function. It's found in POSIX, not in the C standards.

Those are low hanging fruits, not premature optimizations…
It’s fine we disagree. That’s all.

Thanks for that correction. strdup() is available in Arduino so I don't think users would split the difference between those two.

And when they fall (fail) your program crashes. You realize we are talking about text processing here. Speed compared to the I/O is not an issue at all. On the other hand getting a program that runs without crashing (so you can debug it) is.
This post is a case in point

Use of string char causes Arduino code to restart

Using strlcpy would at least allowed the user to debug the problem themselves.
But because they used strcpy (as proposed by many postings on this forum) their project ground to a halt.

There is no reason for failing if you are diligent.
It means testing when it’s due, wether using the l (or n when appropriate) version of the cString functions or just doing the maths yourself.
Understanding and mastering what’s going on is important for any array manipulation, so it’s a useful skill to gain.

If you want to continue to argue the necessity of using strcpy/strcat/sprintf methods instead of the safer strlcpy/strlcat/snprintf methods you will need to provide an example sketch that illustrates your point.

So far just a lot of hand waving.

As you may have noticed my approach to this has evolved over time. I am not wedded to any one coding philosophy. If you can provide an example to illustrate your claims of the necessity of speed of operation or ram usage, then I am happy to take those on board.

But without an example sketch, which illustrates when strcpy etc must be used, I cannot justify presenting those unsafe methods as a solution code to a user's question when I know safer, more robust, and less error prone methods are available.

Users of this forum should not be served up below par and out of date solutions.

Your claim is hand waving as well.

You have lots of function choices, you know what they do and what they don’t do. I’m just saying use the suitable approach. There is no need for belt and suspenders if the belt is enough…

Is not hand waving. It is a real example.
Where are your real examples?

It’s a real example of bad code…

Exactly using strcpy is bad code!! That is the whole point!
Using strlcpy would have avoid the crash.
What is you excuse for using the dodgy strcpy instead of strlcpy?

I don’t get the question. Did I write that code?
Using strlcpy avoids the memory issue, but if you don’t test the outcome you don’t have what you expected in the buffer…and your code is probably doing something you did not expect…