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. .
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…
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
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...
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.
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
When you are ready to bring real sketches to the table we can continue. Otherwise just hot air.
I am not here to 'point' score but to refine my understanding of what works in the real world so I can better advise the posters, backed up with real code examples.