Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Either gnu libc is hideously slow and bloated.. (Score 1) 134

I'm sorry, this sounds like a poor rationalization for lack of useful functionality. By this logic, you should crash the program without warning whenever invalid input is detected - it could be an attack since no program should ever provide invalid input to a function. In real life, programs have tons of bugs and diagnostic messages are hugely useful in identifying and then fixing them. Especially since the vast majority of programs are not used in a context where an attack can occur.

A 'paranoid' mode with this behavior may make sense for some people. Most people, especially those in the process of developing the software, would prefer diagnostics when things go wrong.

I disagree. There is a big difference between invalid input to a function (eg trying to convert "abc" to an integer) and a memory corruption bug. In the former case, you can return an error to the caller, and if they were written with enough attention to detail, they can fix the problem and move on, or ask the user for actually valid input, or whatever followup action may be appropriate.

In the case of a memory corruption bug, there is no way to correct the problem and move on. By the time you detect the problem, you're already hosed. You can't even rely on the fact that the program accurately knows what it was in the middle of trying to do. I think crashing is absolutely appropriate here. And if you want to debug it, then attach a debugging to the program or the resulting core dump -- all the same information you would have gotten from printed diagnostics can be found (albeit with more effort). But trying to diagnose a memory corruption bug after the fact like this is the hard way to do it anyway. You really want to catch the corruption as it happens, and the are much better tools for this (valgrind, etc).

Comment Re:Musl's supported architectures (Score 1) 134

What is involved in a port?

This list is probably not absolutely 100% complete, but it should be pretty close:

  • A number of header files defining system call numbers, and structures for interfacing with the kernel. Musl does not require or use the linux kernel headers, so these definitions must be provided by the port itself.
  • Assembly code for making system calls. There's an inline function version, an implementation of the variadic syscall(2) function, and a version for system calls that made as part of functions defined to be cancellation points
  • The main _start entry point, which just needs to align the stack as appropriate for the target ABI and call __libc_start_main
  • A few atomic primitives, probably written in assembly, but some architectures require calling into a kernel helper to implement these
  • Assembly implementations of setjmp/longjmp
  • Assembly to query/poke at the floating point state, for fenv support
  • Assembly for returning from a signal
  • Assembly for a couple threading things (getting/setting the thread pointer, terminating the calling thread)
  • A couple specific system calls. Clone requires an assembly version. A couple architectures return the result of the pipe syscall via registers, which also requires an assembly implementation on those architectures.
  • A little code to handle the few dynamic relocation types particular to the architecture (which are likely to be identical to those used by other architectures, just with different numbers)
  • Optionally, optimized assembly versions for some math functions, memcpy, and such

You can find links to more information on the musl wiki.

Comment Re:define _GNU_SOURCE (Score 2) 134

putw is a non-standard function that musl's headers only expose to programs when they define _GNU_SOURCE.or _BSD_SOURCE. The file that actually implements it, therefore, needs to define one of these in order for the header to expose the declaration, which allows the compiler to verify that the type signatures of the declaration and the definition match.

Comment re: Brain damaged project (Score 3, Informative) 134

Where does it say you have to link the whole thing into your application? Musl supports dynamic linking just fine. The musl developers do have a preference for static linking, so they have better support for it than glibc (see their size comparisons of static linked programs on musl and glibc, for instance). But that doesn't mean you have to use it.

The bit about aiming for correctness is correctness of musl itself. Of course they can't, in general, guarantee that you will write your own code correctly. In theory, they could split the math library out and force you to link against it correctly. But what would be the point? To arbitrarily break broken programs, while having no impact on correct programs? It would also have several downsides.

Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically, which eliminates a small window during upgrade where you might start a new program and have it break because it gets conflicting versions of these components.

There is also code within the main C library (for example, the code to format floating point numbers in printf) which benefits from being able to call functions that are part of the math library.

Comment Musl's supported architectures (Score 3, Informative) 134

You're right that musl doesn't support the same breadth of architectures that glibc does. They currently support x86, amd64, ARM, MIPS, PPC, microblaze, and they have experimental support for superh and x32.

One big advantage they do have is that it's much simpler to add support for a new architecture to musl than it is to add it to glibc. They are interested in supporting more architectures, so I'd expect their list of supported architectures to grow fairly quickly if there are people interested in that support.

Comment glibc is horribly bloated (Score 4, Informative) 134

The first priority on musl is correctness, and they will take a hit to size and speed if that's what's necessary to achieve it. But thus far, they've been doing a good job of achieving correctness without introducing too much bloat.

Take a look at their page on bugs found while developing musl, and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".

Comment Re:Hey, lets burn some books!!! (Score 1) 1695

"Freedom of speech" only applies to Government's interference in forms of speech. [...]

No. I keep seeing this repeated, but it's absolutely not true. Constitutionally-protected free speech only applies to the government's interference in forms of speech. [...]

Look at the post he was replying to:

I'm usually against listening to any far winged nut job, but this is freedom of expression which falls under the first amendment. [...]

Sentex wasn't explicit about it, but in context it's obvious that he was talking about constitutionally-protected free speech.

Comment Re:HTML and Javascript (Score 1) 799

Javascript, maybe. I don't have much experience with it, so I can't comment.

But I have to disagree with HTML. HTML is not programming. Seriously, making a simple webpage in HTML is like typing a document in Word, except typing <b>text</b> instead of hitting the bold button on the toolbar. If that's programming, then typing up a paper for high school English class is too.

HTML _can_ lead into Javascript, PHP, and other facets of web programming. But it's not programming in itself, and if the goal is to introduce him to programming, making him learn HTML before he can start learning programming seems like the wrong way to go about it.

Slashdot Top Deals

The solution to a problem changes the nature of the problem. -- Peer