C to JavaScript

I know a good few hardcore C peeps lurk around here, is this possible?

 (*p)++

yo dawg i hurd you like hurd so we put it in a hurd in your browser

>>1
If you mean converting C to Javascript then yes, for standards-compliant C programs.

Just fake pointers with a pair (array, index). Pointer arithmetics outside the allocation unit are undefined by the standard.

Plus you would have to go for some lengths to provide proper modulo arithmetics. Also, I'm to lazy to look it up, but it is possible that setjmp/longjmp are in the standard, so you'd have to find a way to emulate them somehow.

>>3
>the allocation unit

This is something that scared me about my computer architecture class. The prof showed iterating through an array int a[] by using (*a)++ as shown. What is the pointer a defined as? Multiples of 4 bytes? (For a 32-bit system, obviously.) Does that mean (char*)a would have to multiply the value by 4?

Anything is possible in C.

Imagination is the only limit.

>>4
(*a)++ increments the value pointed at by the pointer. a++ increments the pointer itself.

Each type has a size, as reported by sizeof(a). Due to alignment and stuff if a is a structure, its size could be greater than the sum of sizes of the constituents.

However, it is guaranteed that there are no gaps between items in an array. So if you have item_t * ptr, then ptr + n == (item_t *)((char*)ptr + n * sizeof(item_t))

Remember, all this stuff about "implementation-dependent" and "undefined" things is there only because there are very good reasons for some architectures to implement things in specific ways. Like, very good reasons. All this is not arbitrary, it's not there because the C standard committee hates you, there's clear logic behind almost every decision they made.

I recommend you to read K&R, then download the C99 standard (available for free, by the way) and look up the parts that are still confusing to you. It's much less dry and formal than you expect.

>>3
setjmp/longjmp could be done with one shot continuations if he's willing to cps the javascript, no?

>>7
Easier than that actually. I overcame my laziness and read section 7.13 of the standard. It is unbelievably lax, which is understandable, because it allows to: 1) store a pointer to the current stack frame, 2) restore the current stack frame to the stored value. Nothing more.

If you discard the stack frame by returning from a function which called setjmp, the behaviour is undefined.

All global state is guaranteed to remain the same as at the longjmp call. Pay attention: longjmp, not setjmp!

All local state in that frame is undefined -- all your local variables and shit. Ain't that some shit? (actually, the reason behind it is that compilers don't have to disable using registers for variables or somehow try to store them on setjmp and restore on longjmp).

Basically, this shit is required to do exactly these two things I said, and the standard describes it in so many words.

So I think you can emulate it with a simple try/catch in JS. Probably. That is, no need to convert any code to CPS, the part of all locals being undefined is extremely powerful. This thing is nowhere close to call-cc.

>>8
Well, I assumed it was just a pointer for setjmp/longjmp.
So I think you can emulate it with a simple try/catch in JS.
Yes, probably, though presumably this would make setjmp/longjmp have to be special forms and not be available as library functions?
This thing is nowhere close to call-cc.
And how, so few guarantees.

For the record, a js translation of
(define (setjmp! env)
  (call/1cc (lambda (k)
             (env-set! env k)
             0)))
(define (longjmp! env val)
  ((env-get env)
   (if (zero? val)
       1
       val)))
should work, with the proviso that if the setjmping function returns it doesn't invalidate the stack context.

>>9
Yes, probably, though presumably this would make setjmp/longjmp have to be special forms and not be available as library functions?

Well, obviously the idea is to write a translator from C to JS, not to somehow implement all the necessary functions to allow for untranslated C execution as if it were JS.

And if you were wondering about that other thing,
It is unspecified whether setjmp is a macro or an identifier declared with external linkage. If a macro definition is suppressed in order to access an actual function, or a program defines an external identifier with the name setjmp, the behavior is undefined.

>>10
The latter addresses my point, which I guess would have better been expressed as "in the translated JS program the body of the function after the setjmp would need to be in the body of the catch, so you couldn't create a js function for setjmp".

Huh, intelligent discussion. This is odd.

催淫通販:http://www.china-seiryokuzai.com/view/sfdwu.html
Wenickman:http://www.china-seiryokuzai.com/view/wk.html
ナンパオ:http://www.china-seiryokuzai.com/view/nanbao.html
狼1号:http://www.china-seiryokuzai.com/view/langyihao.html
狼一号:http://www.china-seiryokuzai.com/view/langyihao.html
巨根カプセル:http://www.china-seiryokuzai.com/view/jugen.html
ベニクモ:http://www.china-seiryokuzai.com/view/hongzhizhucqf.html
D10 媚薬:http://www.china-seiryokuzai.com/view/meiyao.html
催情剤:http://www.china-seiryokuzai.com/view/meiyao.html
花痴:http://www.china-seiryokuzai.com/view/huachi.html

Never mind.

>>12
Intelligent?

dumb.

>>9
gtfo lithpfag

>>17
gtfo fiocfag

>>18
FUCK OFF AND DIE YOU MOTHERFUCKING FAGGOT ALREADY

LANGUAGES ARE NOT JUST SYNTAX
MOST THINGS DON'T TRANSLATE WELL