One of the programming challenges at SPOJ involves writing code in.bf, where input validation is practically infeasible. While there wasn't a chance for arbitrary code, an unexpected value could still disrupt the program. With other esoteric programming languages, input validation would be a luxury, and it's no surprise that something theoretical would come out.
When I followed a few links, I came across a sample exploit [github.io], but I don't see why it's an exploit, nor do I understand what said machine is trying t
Or creating an input subroutine rather than doing input directly. It's not like I was required to use.bf, there was also the choice of Intercal which gets close to implementing that feature.
That's a good question. The answer is likely to revolve around whether or not you can build up reusable primitives that the macro processor can reuse.
For example, if you can write code to print a string to the terminal, then the macroprocessor can use that and you now only have to write once command to print a string. This is similar to what we do with assembly: build primitives and reuse them instead of writing raw assembly every time.
Late April Fools (Score:2)
One of the programming challenges at SPOJ involves writing code in .bf, where input validation is practically infeasible. While there wasn't a chance for arbitrary code, an unexpected value could still disrupt the program. With other esoteric programming languages, input validation would be a luxury, and it's no surprise that something theoretical would come out.
When I followed a few links, I came across a sample exploit [github.io], but I don't see why it's an exploit, nor do I understand what said machine is trying t
Re:Late April Fools (Score:2)
writing code in .bf, where input validation is practically infeasible.,
You just need a halfway decent macro processor, and the language is fine.
Re: (Score:2)
Or creating an input subroutine rather than doing input directly. It's not like I was required to use .bf, there was also the choice of Intercal which gets close to implementing that feature.
Re: (Score:2)
Re: (Score:2)
That's a good question. The answer is likely to revolve around whether or not you can build up reusable primitives that the macro processor can reuse.
For example, if you can write code to print a string to the terminal, then the macroprocessor can use that and you now only have to write once command to print a string. This is similar to what we do with assembly: build primitives and reuse them instead of writing raw assembly every time.
Re: (Score:2)
I would suggest m4 then :P
Re: (Score:2)
I've seen it done before [zerobugsan...faster.net].
Although I would say that m4 is a halfway decent macro processor ;)