Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

I'm conflicted about this one. I choose not to try and emulate generics with macros because adding language features with macros is a terrible idea. On the other hand, I recognize the problem with void*. It's a matter for debate but I definitely fall on the "don't use macros for this" side.

This is a case where I would rather write more code than rely on magic. You have to have this awful hacky opaque implementation in exchange for a trivial improvement in ergonimics. No thanks.

I mean, just look at this code. Or better yet, have someone else look at it. This is totally unreadable and unmaintainable, all for a marginal ergnomics improvement.

Just use strtol or strtof. Do you really run into this that often?

All of these are demonstrating exactly the problem I have with a lot of C authors. You build these esoteric systems that use heaps of unmaintainable, unreadable code to provide marginal gains elsewhere.

View on HN

Just use strtol or strtof

Which of these is more likely to have bugs?

    int i;
    
    if (PARSENUM(&i, s, 0, 1000))
        err("Invalid input: %s", s);

    int i;
    long l; // need a temporary long to avoid overflow
    char * ep;
    
    errno = 0;
    l = strtol(s, &ep, 0);
    if ((ep == s) || (*ep = '\0'))  // make sure we parsed a number and don't have trailing garbage
        errno = EINVAL;
    if ((l < 0) || (l > 1000))
        errno = ERANGE;
    if (errno)
        err("Invalid input: %s", s);
    i = l;

You build these esoteric systems that use heaps of unmaintainable, unreadable code

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.

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.

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?

>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?

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.

>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!

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.

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-...

> 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

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.

> 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".

> 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.

Wouldn't it be possible to just expose parsenum_float, parsenum_signed and parsenum_unsigned instead of the macro interface?

#define IT "I think" // :)

>2 IT the swicth/cases are quicker/clearer to grasp than the one with BIGMACROS_X

>4 IT you shouldn't underestimate the existing neural paths of knowledge of stdlib for C devs. those std functions are read / parsed almost intuitively, unlike cute macros, except for their creator.

I'am ll for "cleaning" C and have a non-completely backwards dependent / improved standard, but I'd much prefer strtof than a custom macro. And those standard C functions are often accelerated to death by compilers (see: memcpy by example).

So others' argument is: I have macro I don't have to read code at all Your argument is: macros a bad, so have explicit code everywhere. This of course makes it to be readable a must.

For me clearly named macro beats the need to parse few lines of code even if they are very clear and readable.

Reply on news.ycombinator.com