s/String discussion (again)

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…

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: