SoylentNews is people
SoylentNews
from the ilibc-ulibc-we-all-C-for-libc dept.
dalias writes
"The musl libc project has released version 1.0, the result of three years of development and testing. Musl is a lightweight, fast, simple, MIT-licensed, correctness-oriented alternative to the GNU C library (glibc), uClibc, or Android's Bionic. At this point musl provides all mandatory C99 and POSIX interfaces (plus a lot of widely-used extensions), and well over 5000 packages are known to build successfully against musl.
Several options are available for trying musl. Compiler toolchains are available from the musl-cross project, and several new musl-based Linux distributions are already available (Sabotage and Snowflake, among others). Some well-established distributions including OpenWRT and Gentoo are in the process of adding musl-based variants, and others (Aboriginal, Alpine, Bedrock, Dragora) are adopting musl as their default libc."
(Score: 4, Informative) by threedigits on Thursday March 20 2014, @05:45PM
Here goes my karma, but hey, what the hell.
Len prefixed strings are, to paraphrase Linus Torvals, insane.
For being competitive in terms of efficiency you need to use the native word size in the native endianess. This kills their use as an interchange format. And years and years of benchmarks have proved that it doesn't have any real advantage, because most strings are short, and in those cases the scan time is mostly negligible (and any sane code does it only once).
Also, they are NOT more secure. Just try to use a 16-bit prefixed string as a 32-bit one and have a lot of fun.
So, null terminated strings are universal, as safe and as fast as the alternatives for most uses. Don't expect Linux changing any time soon.
(Score: 1) by Desler on Thursday March 20 2014, @06:01PM
Why should you think you'll burn karma? You're absolutely write. For string lengths of even 100 or less characters will take fractions of a second and that's against ancient Pentium 4s. It is highly doubtful that the overhead of strlen is a hotspot in the vast of programs and if it is then it's usually due to some idiot calling it repeatedly for the same string rather than caching the value.
(Score: 0) by Anonymous Coward on Thursday March 20 2014, @06:03PM
Absolutely right of course. Facepalm at myself.
(Score: 0) by Anonymous Coward on Thursday March 20 2014, @06:22PM
I agree. NULL vs Pascal gains you nothing other than a library headache.
Instead of attacking the end of the string what stops me from memory underrun and attacking the size? Not only that I know exactly where to attack instead of having to search for it.
The only security it would give you is for the short while it took for hackers to figure out how to attack it.
(Score: 1) by ArghBlarg on Thursday March 20 2014, @06:26PM
It may not make code more resistant to attack (ie., intentional overflows), but it would help prevent accidental overflows (ie., programmer error).
And if you're concerned about 16-vs 32-bit lengths, standardize on one then. Memory's cheap.
I know I'd like to never have to think about terminating strings again.. it's a stupidly menial task and no matter how careful people try to be, someone somewhere forgets a memset() or a fixup on an snprintf() or strncat() somewhere... and before anyone says "so write a wrapper once that does it right and forget about it".. easy to say for you own code, but you probably use lots of other people's code and if it's third-party libs you do NOT want to go through all of that when the changes won't get pushed upstream.
(Score: 0) by Anonymous Coward on Friday March 21 2014, @03:58PM
but it would help prevent accidental overflows
How? That would *only* work if you made sure to use the libraries for everything. If you are doing that who cares how it is terminated. And then I could just overflow anyway by a stupid cast somewhere (which are trivial to do and usually done at function boundaries), and that is just 1 example. Stupidity is not created from the language. It comes from poor knowledge and bad mistakes.
Memory's cheap.
Yes, if you are building 1 of something it is. If you are building 20k of something not so much.
You are fighting for something that does not exist for C. There is basically no standard 'p-string' type in C. C is a 'buffer' orientated language. I can turn a int64 into a buffer with 1 cast. char * is no different. You can do pstring things in other languages as it is 'built in'.
The language does not do it. Libraries can help you do it though. The C language is fairly simple. It has no concept of 'printf'. The library that goes along with it? Thats a beast.
Feel free though to create a 'pstring' crt. I am sure many would use it.
(Score: 0) by Anonymous Coward on Thursday March 20 2014, @06:28PM
The GGP is probably some "programmer" who only writes in VM-languages with little real-world experience not having his hand held. That usually where most of these inane suggestions come from.
(Score: 1) by ArghBlarg on Thursday March 20 2014, @06:46PM
Wow. Just wow. Why don't you go home with your "air quote" ad-hominem attacks already?
OK Mr. Coward, let's hear your better ideas. And "rewriting libc over-and-over again and patching holes after we find them, with no attempt to fix root causes" isn't an idea. I may not have any ultimate answers, but at least I'm trying to think about them.
Fine, mentioning strlen() was probably a red herring -- that' not really an efficiency issue. But from a computational standpoint, it's still unncecessary (and yes I know compilers may optimize invariants like that in certain situations, buy why should that even be necessary?)
I never said changing how strings were represented would be easy. It's easy to say in hindsight that radical things that turned out well were obviously good.. except it wasn't obvious unless someone did it. (See any successful wheel that's been rewritten 'just cuz' someone wanted to).
BTW my experience is primarily with RTOS and embedded development, so I'm not totally clueless as suggested.