Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by LaminatorX on Thursday March 20 2014, @01:33PM   Printer-friendly
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."

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Informative) by threedigits on Thursday March 20 2014, @05:45PM

    by threedigits (607) on Thursday March 20 2014, @05:45PM (#18976)

    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.

    Starting Score:    1  point
    Moderation   +3  
       Informative=3, Total=3
    Extra 'Informative' Modifier   0  

    Total Score:   4  
  • (Score: 1) by Desler on Thursday March 20 2014, @06:01PM

    by Desler (880) on Thursday March 20 2014, @06:01PM (#18983)

    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

      by Anonymous Coward on Thursday March 20 2014, @06:03PM (#18987)

      Absolutely right of course. Facepalm at myself.

  • (Score: 0) by Anonymous Coward on Thursday March 20 2014, @06:22PM

    by Anonymous Coward on Thursday March 20 2014, @06:22PM (#18999)

    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

      by ArghBlarg (1449) on Thursday March 20 2014, @06:26PM (#19002)

      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

        by Anonymous Coward on Friday March 21 2014, @03:58PM (#19351)

        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

      by Anonymous Coward on Thursday March 20 2014, @06:28PM (#19004)

      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

        by ArghBlarg (1449) on Thursday March 20 2014, @06:46PM (#19018)

        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.