Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recursive macros in C, demystified (once the ugly crying stops)

h4x0r.org

Post reply on HN
Print view View original

31–40 of 90 posts

Re: Recursive macros in C, demystified (once the ugly crying stops)

#31

Post by sltkr »

russfink wrote: post #10

Is this a DoS risk - code that sends your build chain into an infinite loop?

From a DoS risk perspective there is no practical difference between an infinite loop, or a finite but arbitrarily large loop, which was always possible.

For example, this doesn't work:

    #define DOUBLE(x) DOUBLE(x) DOUBLE(x)
    DOUBLE(x)
That would only expand once and then stop because of the rule against repeated expansion. But nothing prevents you from unrolling the first few recursive expansions, e.g.:

    #define DOUBLE1(x) x x
    #define DOUBLE2(x) DOUBLE1(x) DOUBLE1(x)
    #define DOUBLE3(x) DOUBLE2(x) DOUBLE2(x)
    #define DOUBLE4(x) DOUBLE3(x) DOUBLE3(x)
    DOUBLE4(x)
This will generate 2^4 = 16 copies of x. Add 60 more lines to generate 2^64 copies of x. While 2^64 is technically a finite number, for all practical purposes it might as well be infinite.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#32

Post by WalterBright »

viega wrote: post #30
WalterBright wrote: post #26

Imagine trying to implement the C preprocessor. I had to write it from scratch 3 times before it worked 100%.

Wow, you are a braver person than I. Well done.

Thank you. I am actually perversely proud of it.

Re: Recursive macros in C, demystified (once the ugly crying stops)

#36

Post by camel-cdr »

chirsz wrote: post #7

The behavior of C macros is actually described by a piece of pseudocode from Dave Prosser and it is not in the standard: * https://www.spinellis.gr/blog/20060626/ * https://www.spinellis.gr/pubs/jrnl/2006-DDJ-Finessing/html/S... * https://gcc.gnu.org/legacy-ml/gcc-prs/2001-q1/msg00495.html

This is the best explanation I've seen so far:

https://marc.info/?l=boost&m=118835769257658&w=2

Re: Recursive macros in C, demystified (once the ugly crying stops)

#38

Post by procaryote »

In many ways being limited ends up being a feature. Even limited as it is, you get some crimes against humanity like the bourne shell source, but at least most people agree it is a bad idea

If it allowed more unlimited metaprogramming, building big complex things as macros might well have become popular

Re: Recursive macros in C, demystified (once the ugly crying stops)

#39

Post by procaryote »

MangoToupe wrote: post #37

The c pre processor. C doesn't have macros. It's fucking miserable. Anyone who uses it is a masochist

It's a feature... macros allows people to change the language at will which is great when you're researching programming languages (like in lisp) but less good when you want maintainable and consistent code

C++ has more powerful metaprogramming and look how that turned out

Re: Recursive macros in C, demystified (once the ugly crying stops)

#40

Post by MangoToupe »

procaryote wrote: post #39
MangoToupe wrote: post #37

The c pre processor. C doesn't have macros. It's fucking miserable. Anyone who uses it is a masochist

It's a feature... macros allows people to change the language at will which is great when you're researching programming languages (like in lisp) but less good when you want maintainable and consistent code C++ has more powerful metaprogramming and look how that turned out

No, it is not a feature. It prevents C from being parseable and precludes actual metaprocessing. Just use lisp if you want to write maintainable code

Nobody wants to end up like C++ of course, you ain't wrong about that

Post reply on HN