>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.
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?
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?
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.
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!
Not niche at all. You should have a range check on pretty much every value you accept from a command-line option.
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-...
A few years ago. 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.
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); \
} \
...
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.