2 ms·

To be honest I would just have your library offer a function that does it your fancy way. I agree that there could be better integer parsing functions, I disagr

To be honest I would just have your library offer a function that does it your fancy way. I agree that there could be better integer parsing functions, I disagree that they should be macros. >Not at all. The point is to have self-contained routines which Just Work in order to ensure that the rest of the code is easier to read and maintain. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. Not worth it.

cperciva 10y ago
To be honest I would just have your library offer a function that does it your fancy way. It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. All of my macros are intelligible to anyone who understands the C preprocessor. 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?
- Sir_Cmpwn 10y ago
  >It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Just tack an 'i' or 'f' or 'l' on the end. Not a big deal. Literally one extra character. And you don't have to hold shift the whole time. >All of my macros are intelligible to anyone who understands the C preprocessor. I understand the C preprocessor fine and I have to stop and mentally decode all the crap your macros are trying to do. >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? All code is liable to have bugs. All code is liable to have performance issues. All code is liable to use an outdated syntax or features in 10 years. What if the stdlib does improve and adds functions that supplant these? What if they do so only partially? What if your functions could be improved to rely on a new stdlib function that's safer/faster/etc?
  - cperciva 10y ago
    Just take an 'i' or 'f' or 'l' on the end. Not a big deal. Literally one extra character. I don't think you understand. At a minimum, you would need parsenumi, parsenuml, parsenumll, parsenumimax, parsenumu, parsenumul, parsenumull, parsenumumax, parsenumi8, parsenumi16, parsenumi32, parsenumi64, parsenumu8, parsenumu16, parsenumu32, parsenumu64, parsenumf, and parsenumd. All code is liable to use an outdated syntax or features in 10 years. What if the stdlib does improve and adds functions that supplant these? What if they do so only partially? What if your functions could be improved to rely on a new stdlib function that's safer/faster/etc? This is C, not perl. Features don't become "outdated" in a mere 10 years. And if there is a new standard library function which is useful here... well, (a) I wouldn't want to use it for at least 20 years, and (b) I'd probably be one of the people writing said standard library function, so I'd have no difficulty updating my macros.
    - Sir_Cmpwn 10y ago
      >I don't think you understand. At a minimum, you would need parsenumi, parsenuml, parsenumll, parsenumimax, parsenumu, parsenumul, parsenumull, parsenumumax, parsenumi8, parsenumi16, parsenumi32, parsenumi64, parsenumu8, parsenumu16, parsenumu32, parsenumu64, parsenumf, and parsenumd. Fair. I still don't really see the value in this, though. The only real gain is from doing the range check, and that's niche enough that I'd just write a function for the particular project that demands it, and I'd only have to write one function because there'd likely only be one integer type it's relevant to. >This is C, not perl. Features don't become "outdated" in a mere 10 years. And if there is a new standard library function which is useful here... well, (a) I wouldn't want to use it for at least 20 years Fair enough. >I'd probably be one of the people writing said standard library function I hope not!
      - cperciva 10y ago
        that's niche enough Not niche at all. You should have a range check on pretty much every value you accept from a command-line option.
- 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.
- ufo 10y ago
  Wouldn't it be possible to just expose parsenum_float, parsenum_signed and parsenum_unsigned instead of the macro interface?

cperciva 10y ago

To be honest I would just have your library offer a function that does it your fancy way. It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Self-contained routines that are completely unmaintainable and unintelligible to anyone but you, though. All of my macros are intelligible to anyone who understands the C preprocessor. 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?

Sir_Cmpwn 10y ago
>It's not possible to have a single function do this. Not possible to have any finite number of functions do this if, like me, you want to support all floating-point and integer types. Just tack an 'i' or 'f' or 'l' on the end. Not a big deal. Literally one extra character. And you don't have to hold shift the whole time. >All of my macros are intelligible to anyone who understands the C preprocessor. I understand the C preprocessor fine and I have to stop and mentally decode all the crap your macros are trying to do. >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? All code is liable to have bugs. All code is liable to have performance issues. All code is liable to use an outdated syntax or features in 10 years. What if the stdlib does improve and adds functions that supplant these? What if they do so only partially? What if your functions could be improved to rely on a new stdlib function that's safer/faster/etc?
- cperciva 10y ago
  Just take an 'i' or 'f' or 'l' on the end. Not a big deal. Literally one extra character. I don't think you understand. At a minimum, you would need parsenumi, parsenuml, parsenumll, parsenumimax, parsenumu, parsenumul, parsenumull, parsenumumax, parsenumi8, parsenumi16, parsenumi32, parsenumi64, parsenumu8, parsenumu16, parsenumu32, parsenumu64, parsenumf, and parsenumd. All code is liable to use an outdated syntax or features in 10 years. What if the stdlib does improve and adds functions that supplant these? What if they do so only partially? What if your functions could be improved to rely on a new stdlib function that's safer/faster/etc? This is C, not perl. Features don't become "outdated" in a mere 10 years. And if there is a new standard library function which is useful here... well, (a) I wouldn't want to use it for at least 20 years, and (b) I'd probably be one of the people writing said standard library function, so I'd have no difficulty updating my macros.
  - Sir_Cmpwn 10y ago
    >I don't think you understand. At a minimum, you would need parsenumi, parsenuml, parsenumll, parsenumimax, parsenumu, parsenumul, parsenumull, parsenumumax, parsenumi8, parsenumi16, parsenumi32, parsenumi64, parsenumu8, parsenumu16, parsenumu32, parsenumu64, parsenumf, and parsenumd. Fair. I still don't really see the value in this, though. The only real gain is from doing the range check, and that's niche enough that I'd just write a function for the particular project that demands it, and I'd only have to write one function because there'd likely only be one integer type it's relevant to. >This is C, not perl. Features don't become "outdated" in a mere 10 years. And if there is a new standard library function which is useful here... well, (a) I wouldn't want to use it for at least 20 years Fair enough. >I'd probably be one of the people writing said standard library function I hope not!
    - cperciva 10y ago
      that's niche enough Not niche at all. You should have a range check on pretty much every value you accept from a command-line option.
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.
ufo 10y ago
Wouldn't it be possible to just expose parsenum_float, parsenum_signed and parsenum_unsigned instead of the macro interface?