3 ms·

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

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.
      - irundebian 10y ago
        cperciva, sorry, but you're these type of people who should be kept away from security critical code. It's not that I would doubt in any way your deep knowledge of the C language, quite the opposite, it's just your arrogance, your mentality of elitism and your belief, that you don't belong to the people, who are making mistakes (like "because of XYZ years of experience" bullshit). IMHO if you want to write good code (especially safety-critical code) it is a FUCKING MUST to believe that you or others who are working on your code will make mistakes, caused by badly readable code. The mental model caused by reading your code have to be minimized as heavy as possible. But I guess the problem of people like you with writing clean and readable code is, that you can't show your knowledge and experience built over several years. This behavior reminds be of philosophers (also social scientists) criticized by Karl Popper as "obscurantists", which are preferring to describe simple issues in a complex language to show how intellectual they are, although they could be well described in a clean and a simple way, so that everybody understands them. I'm highly surprised that your still behaving arrogant, advocating complex macros and act as you have never made a mistake when dealing with code. Open your eyes and deal with the fact that YOU are one of the people who devaluated the whole security promise of a security critical software [0]. YOU are one of the people as we all are, that are making mistakes. Be it by deliberately removing increment operators of an IV or by a fault caused by a misunderstand of unnecessary complex code. [0] http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...
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?

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.
    - irundebian 10y ago
      cperciva, sorry, but you're these type of people who should be kept away from security critical code. It's not that I would doubt in any way your deep knowledge of the C language, quite the opposite, it's just your arrogance, your mentality of elitism and your belief, that you don't belong to the people, who are making mistakes (like "because of XYZ years of experience" bullshit). IMHO if you want to write good code (especially safety-critical code) it is a FUCKING MUST to believe that you or others who are working on your code will make mistakes, caused by badly readable code. The mental model caused by reading your code have to be minimized as heavy as possible. But I guess the problem of people like you with writing clean and readable code is, that you can't show your knowledge and experience built over several years. This behavior reminds be of philosophers (also social scientists) criticized by Karl Popper as "obscurantists", which are preferring to describe simple issues in a complex language to show how intellectual they are, although they could be well described in a clean and a simple way, so that everybody understands them. I'm highly surprised that your still behaving arrogant, advocating complex macros and act as you have never made a mistake when dealing with code. Open your eyes and deal with the fact that YOU are one of the people who devaluated the whole security promise of a security critical software [0]. YOU are one of the people as we all are, that are making mistakes. Be it by deliberately removing increment operators of an IV or by a fault caused by a misunderstand of unnecessary complex code. [0] http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-security-bug.html http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...

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?