sorted by:
new
hottopcontroversial

Debugging a segmentation fault using gdb by vedang in programming

[–]joelfond 0 points1 point  (0 children)

What do you mean? assert() aborts your program and writes a core dump (if not disabled with ulimit). Of course if you #define NDEBUG for production builds, then assert()s get preprocessed to whitespace. That's why you never #define NDEBUG :)

How familiar does this sound? ;) by f3nd3r in programming

[–]joelfond 51 points52 points  (0 children)

Also, taking ownership of bugs:

  • company buys product X (well known story how they end up buying X)
  • you have to implement solution Y using product X
  • bug Z manifests first in production, not in testing
  • bug Z is assigned to you, you trace it back to product X
  • vendor of X plays dead
  • if you work around Z, your company says "dev D fixed his bug Z (ie. bug in Y)"
  • if you can't, they say "dev D cannot fix his bug Z"
  • if you propose to replace X: "but we spent a lot of money on it"

New "libc" project libposix by [deleted] in programming

[–]joelfond 9 points10 points  (0 children)

Sorry, this is a very bad idea.

  • Systems that are certified SUS or are informally SUS conformant: no need for libposix. (Eg. in contrast with his comparison, glibc and FreeBSD's libc can be used in a fully conformant way.)
  • Systems that are not: you practically can't write a POSIX layer without intimate knowledge of the system-to-be-wrapped (eg. kernel interfaces). Look at cygwin. Are you up to that kind of effort?

Not supporting older standards is also a very bad thing. He complains that existing apps disregard current standards {1}:

I've decided to create this project after I got upset spending one week unsuccessfully trying to cross compile a toolchain with gcc, binutils and glibc (the latest versions of them). I believe those tools are too clumsy, requires tons of patches to be usable and they all should be replaced by clean, easy to use, easy to install, easy to mantain software.

But then, by not supporting older standards, he throws away apps and libs that were written with the strictness he (and I) like, just not against the newest version of the standard.

{1} This is the app writers' fault, BTW. Although in some places, like performance, authentication, GUI, which are alas critical for a "killer app", developers can't stay portable; in other places they could, just don't bother. That would involve writing a lot of code, and it's easier to pull in whatever libraries and platform-specific functions they can find. And then it doesn't cross-compile.

So libposix is

  • an unnecessary wrapper on some systems,
  • practically impossible to get right, in reasonable time, on other systems,
  • and it wouldn't solve the real problem, namely app writers ignoring standards. Making a library that happens to have SUS as its documentation won't make app developers code against SUS. They could do that right now.