| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 10, 2010 20:10 UTC (Wed) by jwb (guest, #15467)In reply to: Glibc change exposing bugs by corbet Parent article: Glibc change exposing bugs
There are a huge variety of improvements to Linux which have broken or will break Flash Player, for example Flash abused the ALSA API until Pulse came along and exposed that abuse.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 10, 2010 20:38 UTC (Wed) by neilbrown (subscriber, #359) [Link] This all sounds like a very strong recommendation in favour of Rusty Russell's Maxim of API development: APIs should be hard to misuse. memcpy, and apparently ALSA, are easy to misuse.So implementing memcpy as memmove - which Linus says in the bugzilla threads is largely what the kernel does - sounds very sensible. memmove is much harder to misuse.
Glibc change exposing bugs Posted Nov 13, 2010 1:07 UTC (Sat) by rriggs (subscriber, #11598) [Link]
memmove: safe, fast, verbose function name
memcpy: unsafe, at least as fast as memmove, one less character to type
Which one do you think your average C programmer will choose?
Which one do you think new programmers are taught to use (in schools that still teach C programming)?
Glibc change exposing bugs Posted Nov 13, 2010 2:52 UTC (Sat) by neilbrown (subscriber, #359) [Link]
So we can save the world by creating a 'memmv' in glibc which aliases memmove? Brilliant!
Glibc change exposing bugs Posted Nov 15, 2010 16:43 UTC (Mon) by renox (subscriber, #23785) [Link]
Too late!
And memcpy should also be named as mem_unsafe_copy, but yes if you tell developers to use safe function by default and to optimize only when they can show benchmarks that the optimisation will make a difference, then yes, you'd get probably better software (if a bit slower).
Glibc change exposing bugs Posted Nov 25, 2010 15:13 UTC (Thu) by Spudd86 (guest, #51683) [Link]
It's not so much that ALSA is easy to misuse (although it probably is), it's that certain parts of it are impossible to emulate from userspace. An app that actually NEEDS those parts is NOT misusing the API when it uses them (for example, pulseaudio itself uses those bits).
The problem is that most apps don't actually need the those bits, so they just needlessly break software like pulseaudio (and also break on bluetooth audio too).
Pulseaudio does use those unemulatable APIs, but it also falls back if they don't work, and it has good reasons to use those APIs (so it can hand over large chunks of audio data, but still be able to decide it wants to change that same data later (if for example something else starts playing audio), this saves you power because pulse won't wake your CPU as much, but it also uses APIs that don't emulate well AND until pulse came along nobody ever tried to do that sort of thing so it broke)
Glibc change exposing bugs Posted Nov 25, 2010 16:07 UTC (Thu) by foom (subscriber, #14868) [Link]
If the documentation wasn't so terrible, this probably wouldn't be a problem. It doesn't give *any* clue that, for example, a developer shouldn't use the mmap functions. In fact it makes it sound like you should use them, because they're zero-copy (and that's better, right?)
Glibc change exposing bugs Posted Nov 25, 2010 16:39 UTC (Thu) by Spudd86 (guest, #51683) [Link]
Well yea, but Lennart Pottering does have a blog post where he says exactly what subset of ALSA's API you should restrict yourself to, perhaps someone should put that into the ALSA docs.
|
|||||||||||||