diff --git a/1986/marshall/compilers.md b/1986/marshall/compilers.md index 406241681..333b54d91 100644 --- a/1986/marshall/compilers.md +++ b/1986/marshall/compilers.md @@ -93,6 +93,11 @@ eventually could? Whichever you wish it to be, it now works with both clang and gcc! Choo choo! +
+ +Jump to: [top](#) + + /* ... */ @@ -67,27 +67,27 @@ ints: } ``` - First of all: why do I set `e[2]` to 0 and increment it for each pass in the - loop, but then the condition for the loop is `s[*P]`? +First of all: why do I set `e[2]` to 0 and increment it for each pass in the +loop, but then the condition for the loop is `s[*P]`? - Second notice the many references to e[1] (as e[1] and *g). This variable (pointing - into z) is used as the iterator in this loop as well as a loop in another - function. Now why do I pass *g to the function w()? To mislead. Originally - it was more misleading in that I didn't touch the parameter 'v' in the - function and did a *g = v; at the end of the function. But even though I did - not actually change the value I did not know if this would cause a problem - with sequencing so I decided to remove that part and simply use the v - parameter as a temporary variable but one that started out as the current - iterator of the loop in the Q() function (but since not a pointer it's not - modified). +Second notice the many references to e[1] (as e[1] and *g). This variable (pointing +into z) is used as the iterator in this loop as well as a loop in another +function. Now why do I pass *g to the function w()? To mislead. Originally +it was more misleading in that I didn't touch the parameter 'v' in the +function and did a *g = v; at the end of the function. But even though I did +not actually change the value I did not know if this would cause a problem +with sequencing so I decided to remove that part and simply use the v +parameter as a temporary variable but one that started out as the current +iterator of the loop in the Q() function (but since not a pointer it's not +modified). - Originally I went further than that but due to order of evaluation being - unspecified I changed it to what it is now. Anyway: +Originally I went further than that but due to order of evaluation being +unspecified I changed it to what it is now. Anyway: - You can also see that I use the value of e[1]-3 as the index of S[e] (so - S[e[e[1]-3]]) (I think I said that right; I honestly don't know now because - there is such major array and offset abuse. The entire prog.c is riddled - with offset abuses.). +You can also see that I use the value of e[1]-3 as the index of S[e] (so +S[e[e[1]-3]]) (I think I said that right; I honestly don't know now because +there is such major array and offset abuse. The entire prog.c is riddled +with offset abuses.). * If you observe that above the compound literal `z` is of size 13 but I point @@ -107,12 +107,12 @@ address `e[1]`. Thus I also have: } ``` - This `e[1]` of course is the same as `*g` as above and as you can see has - multiple dimensions (that is the reference to Y does) too (and this is also - strewn about the code). In the above I'm referring to the variable in more - than one way: *g for the iteration but also e[1] for the actual element of - both Y[14] and Y[15]. I also happen to use S (via r which points to S + 10) - which I use as the two chars to compare (this is the plugboard function). +This `e[1]` of course is the same as `*g` as above and as you can see has +multiple dimensions (that is the reference to Y does) too (and this is also +strewn about the code). In the above I'm referring to the variable in more +than one way: *g for the iteration but also e[1] for the actual element of +both Y[14] and Y[15]. I also happen to use S (via r which points to S + 10) +which I use as the two chars to compare (this is the plugboard function). * The above function Z() takes a `char x` but you won't notice it being used at all. Why? In fact I call it like so: @@ -121,12 +121,12 @@ at all. Why? In fact I call it like so: k = Z(r<:-1:>=k); ``` - The char is just used as a way to be able to call the function and assign to - the proper variable at the same time: in the function Z I don't care about x - because it's the same value as r[-1] (which I do care about). Why is it - attached to S? Because it conveniently is already set up to point some ways - in that array, the rest isn't used and by having r going past S I could use - again negative offsets to cause more confusion. +The char is just used as a way to be able to call the function and assign to +the proper variable at the same time: in the function Z I don't care about x +because it's the same value as r[-1] (which I do care about). Why is it +attached to S? Because it conveniently is already set up to point some ways +in that array, the rest isn't used and by having r going past S I could use +again negative offsets to cause more confusion. * Although this is clearly already shown in the above there are other ways I refer to the same variable in more than one way (or in some cases maybe more @@ -198,31 +198,31 @@ obfuscation but rather to save bytes. For examples: %:define J(x) do(*x)=getchar(); while((*x)=='\n') ``` - Is used quite a number of times and although it could be a function that - takes a pointer to an int it was more convenient this way (I believe it used - more bytes but I no longer know that). There are many others and they all - save bytes (or at least most of them do if not all). There is one in - particular I want to bring up though because I think it's a curious one and - it ties in to another point above: +Is used quite a number of times and although it could be a function that +takes a pointer to an int it was more convenient this way (I believe it used +more bytes but I no longer know that). There are many others and they all +save bytes (or at least most of them do if not all). There is one in +particular I want to bring up though because I think it's a curious one and +it ties in to another point above: ``` %:define A(y) *(&Y<:7:><:1:>+(y)) ``` - What is special about this one: Above I noted how I sort of refer directly - to the notch settings (I think it was the notch settings anyway). Now I - could have done say +What is special about this one: Above I noted how I sort of refer directly +to the notch settings (I think it was the notch settings anyway). Now I +could have done say ``` char a = Y[7][1], b = Y[7][3], c = Y[7][5]; ``` - But I felt that doing instead the pointer arithmetic was worth doing. - However it used significantly more bytes even as a macro: 17 if I recall - right. That's with the macro. If I were to include it three times by itself - it'd be many more. I believe though that when the cpp translates it it still - requires more thought to determine that a is set to Y[7][1], b to Y[7][3] - and c to Y[7][5]. +But I felt that doing instead the pointer arithmetic was worth doing. +However it used significantly more bytes even as a macro: 17 if I recall +right. That's with the macro. If I were to include it three times by itself +it'd be many more. I believe though that when the cpp translates it it still +requires more thought to determine that a is set to Y[7][1], b to Y[7][3] +and c to Y[7][5]. # Obfuscation wrt recode.c @@ -255,11 +255,16 @@ variables in recode.c, move them to prog.c, compile and expect it to work right. ``` - Is that valid and if so how does it function? Yes it's valid but I'll leave - the other part of the question up to the reader to answer. Hint: you already - know how it works (yes, really you do)! Another hint: This is and is not a - misleading comment (conversely this makes this hint both misleading - and - also not). +Is that valid and if so how does it function? Yes it's valid but I'll leave +the other part of the question up to the reader to answer. Hint: you already +know how it works (yes, really you do)! Another hint: This is and is not a +misleading comment (conversely this makes this hint both misleading - and +also not). + + +
+ +Jump to: [top](#)