3 ms·

> More to the point, why do they need to be maintainable? When was the last time you maintained the strtof function in your C library? A few years ago. https:/

by mfukar 10y ago

> More to the point, why do they need to be maintainable? When was the last time you maintained the strtof function in your C library? A few years ago. https://sourceware.org/bugzilla/show_bug.cgi?id=15744 https://sourceware.org/bugzilla/show_bug.cgi?id=15744 Acting like you can get anything done right in C simply because it's self-contained is proven wrong every day. It's good practice, yes, but doesn't magically (we like this word now) make us immune to error. Everything needs to be maintainable, even if it is proven to be correct, for the simple reason that we can't just replace broken pieces of code with the same simplicity we can replace a broken fridge. Also, if there's anything we know about code, is that we are constantly trying to invent new ways to expose it to a new interface - thereby breaking it.

camgunz 10y ago
> we can't just replace broken pieces of code with the same simplicity we can replace a broken fridge. Sure we can. Recompile glibc, dynamic linking, pow. I wouldn't say that bug you referenced is a strike against C; it could happen in any language that was locale-aware and parsing floats. For what it's worth, these macros in libcperciva are perfectly readable and maintainable: #define ELASTICARRAY_DECL(type, prefix, rectype) \ static inline struct prefix##_struct * \ prefix##_init(size_t nrec) \ { \ struct elasticarray * EA; \ \ EA = elasticarray_init(nrec, sizeof(rectype)); \ return ((struct prefix##_struct *)EA); \ } \ ... The advice should really be "be careful, it's really easy to write shitty macros, so don't".
- mfukar 10y ago
  > Sure we can. Recompile glibc, dynamic linking, pow. Oh, so I have to maintain glibc. That's the alternative, we are in complete agreement. > I wouldn't say that bug you referenced is a strike against C; it could happen in any language that was locale-aware and parsing floats. I was responding to a very specific (and pointed) question. > For what it's worth, these macros in libcperciva are perfectly readable and maintainable: I'm not contesting that, they might be. The one you list looks fine at a glance, but that doesn't prove anything.

by mfukar 10y ago

camgunz 10y ago

> we can't just replace broken pieces of code with the same simplicity we can replace a broken fridge. Sure we can. Recompile glibc, dynamic linking, pow. I wouldn't say that bug you referenced is a strike against C; it could happen in any language that was locale-aware and parsing floats. For what it's worth, these macros in libcperciva are perfectly readable and maintainable: #define ELASTICARRAY_DECL(type, prefix, rectype) \ static inline struct prefix##_struct * \ prefix##_init(size_t nrec) \ { \ struct elasticarray * EA; \ \ EA = elasticarray_init(nrec, sizeof(rectype)); \ return ((struct prefix##_struct *)EA); \ } \ ... The advice should really be "be careful, it's really easy to write shitty macros, so don't".

mfukar 10y ago
> Sure we can. Recompile glibc, dynamic linking, pow. Oh, so I have to maintain glibc. That's the alternative, we are in complete agreement. > I wouldn't say that bug you referenced is a strike against C; it could happen in any language that was locale-aware and parsing floats. I was responding to a very specific (and pointed) question. > For what it's worth, these macros in libcperciva are perfectly readable and maintainable: I'm not contesting that, they might be. The one you list looks fine at a glance, but that doesn't prove anything.