(FTFY) I am fully aware of that subscripting in turn is syntactic sugar; I agree however that it wasn't the best way to put it. It was sufficient for the point I was trying to make, anyway.
and 6.3.2.3.
Well it explicitly says there that the results are implementation-defined -- i.e. outside the scope of what C defines. Kind of supporting my point, thanks.
With some practice, you can time the gas and the clutch just right so that the wheels will lose traction ("spin") when starting yet the engine doesn't go to insanely high RPM ("revving").
That does not work with lower-hp engines. Please find out at what revs you get the highest torque out of common gasoline engines.
I drive a 1500cc proton saga, I can do exactly this without going above 4k rpm. would you consider 1500cc to be 'lower-hp' because I would.
Well, I wouldn't. Furthermore, I wonder how 4k rpm is not revving.
And this can even be done with a very modest engine
No.
yes, back in the 90's when looking for my first cheap car, I test drove an old 850cc mini, that could spin up the tires on the flat in the dry without ringing the crap out of it
Well, since to you 'ringing the crap out of it' seems to start somewhere above 4k rpm, I'm inclined to believe that either the road didn't have much traction, or you were in fact ringing the crap out of it.
all that's needed is mastership of the pedals...
...and the way you keep talking about "mastership of the pedals" makes me suspect that this is a skill you very recently acquired. Otherwise you would kind of realize it's no big deal, and fairly easy to master.
some people go their whole lives never mastering the manual transmission, it's an important skill to learn which I think is why the poster brought it up.
How big of a deal it is probably depends a bit on where one lives.
While that sounds good, it really does not work that way. There isn't really a 'permission granting' step when, say, exploiting some program. You typically 'just' get to run your code in the context of the exploited program. No permissions 'become available' or 'get lost' in the process, at least as far as the OS can tell.
Now if the vulnerability is know, you could program something like that around it -- but then you could just fix the vulnerability in the first place
Oh, yes, it's not like any program is ever dealt with on the user level, with multiple interactions along the way. Literally everything is a shell script. I had forgotten.
Bit of a weird assumption that only shell script execution would yield an exit status when every program (actually: every process, even on Windows, which you're obviously using) does that.
As to what programs, any number of web apps are an easy example.
Gosh...
I forget what slashdot uses as it's message, but when I'm done and hit submit, I'll see an informative message.
Now this isn't even true, and I'm pretty sure you felt quite stupid after submitting. The 'success message' you get from/. is your comment actually showing up, that's it.
Only by stupid programs which don't follow the golden rule of shutting the hell up as long as nothing goes wrong. Therefore you're much more likely to see a message reading "Permission denied", if anything
then it's the median, but hey, let's try it: {1, 2, 8, 8, 8, 8, 9, 9, 9, 10, 10} 2/11 (~18%) are smaller than the median. 5/11 (~45%) are larger than the median.
I just saw this grossly wrong claim and since it was AC's i didn't bother to come up with a detailed explanation on why exactly it is wrong, but I didn't want it to become +5 Informative either. A likely thing to happen it seems.
int array[32]; and int* blah = &(array[0]); will both point to the exact same element in memory.
``array'' doesn't point anywhere, it's an object in memory of size (32*sizeof (int)) and of type int[32]. [yes, C does have objects.] ``blah'' is another object, of size (sizeof (int*)) and of type int*
Obviously these two things are not remotely "the same" (this was the original claim(*)).
With this out of the way:
If you do an equivalence operator on them, they'll be equal.
In fact (array == blah) will be true in this case, but this is only because there is syntactic sugar involved, and the actual comparison done is (&array[0] == blah).
*(int*)((int)blah+(3*sizeof(int)))
No, this is utter gibberish, and even if some implementation choses to compile it, there would be undefined behaviour. (Protip: you cannot cast pointer types to integer types, and no don't argue that your implementation allows it, or that "heey, pointers are just integers to on the metal" (protip-inside-protip: there is no metal in the C Abstract Machine) If you go that route, you only demonstrate that you have no idea what C is)
(*) Some more reasons for why 'arrays and pointers are the same' is grossly wrong in C:
1. ``but i can assign an array to a pointer!'' -- try assigning a pointer to an array. 2. in fact, try assigning an array/at all/ (no, initialization is not assignment) 3. an array can hold multiple elements, a pointer can hold a memory address 4. in expression context, the array "value" is a pointer to its first element -- if both were the same, that rule would be fairly meaningless. 5....
I love how you add words that absolutely nobody said to prop up your straw man.
Erm that was supposed to be a FTFY kind of reply, if you couldn't tell from the emphasis. It's not a straw-man, it's pointing out the flaw in your plan.
The rest of your comment doesn't really make sense to me, but I lost it at ``MCSE'' anyway.
Staff intensive as in 1 guy per such machine that has expert
It does not scale.
Furthermore, depending on the importance of the machine, you might have to have someone around/all/ the time instead of just 9-5, ending you with needing at least 3 guys plus replacement
Uh. The ambiguity didn't occur to me at all. Reads a bit unnaturally that way, but you're right I should've put a comma there. Sorry for becoming overly annoyed, pretty glad it turned out to be only a missunderstanding
In C, arrays are really just pointers to the first element
No.
, and array[index] is defined through pointer arithmetic: It just means *(array+index). Addition is commutative, so you could just as well write index[array], because that is defined as *(index+array), which is the same as *(array+index).
I'm pretty well-aware of what you can do with opamps and RLC, thanks. Not that you mentioned any RLC in the first place, you also left them out in your price comparison, so why would i assume you did anything more complicated than a buffer?
but even both opamps in some exotic configration don't really match what i was referring to by 'moderately complex system'. two operations are not moderately complex.
Slashdot Mirror
Spoilers available at 6.5.2.1^W6.3.2.1#3
(FTFY)
I am fully aware of that subscripting in turn is syntactic sugar; I agree however that it wasn't the best way to put it. It was sufficient for the point I was trying to make, anyway.
and 6.3.2.3.
Well it explicitly says there that the results are implementation-defined -- i.e. outside the scope of what C defines.
Kind of supporting my point, thanks.
With some practice, you can time the gas and the clutch just right so that the wheels will lose traction ("spin") when starting yet the engine doesn't go to insanely high RPM ("revving").
That does not work with lower-hp engines. Please find out at what revs you get the highest torque out of common gasoline engines.
I drive a 1500cc proton saga, I can do exactly this without going above 4k rpm. would you consider 1500cc to be 'lower-hp' because I would.
Well, I wouldn't. Furthermore, I wonder how 4k rpm is not revving.
And this can even be done with a very modest engine
No.
yes, back in the 90's when looking for my first cheap car, I test drove an old 850cc mini, that could spin up the tires on the flat in the dry without ringing the crap out of it
Well, since to you 'ringing the crap out of it' seems to start somewhere above 4k rpm, I'm inclined to believe that either the road didn't have much traction, or you were in fact ringing the crap out of it.
all that's needed is mastership of the pedals...
...and the way you keep talking about "mastership of the pedals" makes me suspect that this is a skill you very recently acquired. Otherwise you would kind of realize it's no big deal, and fairly easy to master.
some people go their whole lives never mastering the manual transmission, it's an important skill to learn which I think is why the poster brought it up.
How big of a deal it is probably depends a bit on where one lives.
Indeed.
It would at least get rid of the loss of material caused by picking it up and putting it somewhere, then later putting it back, by whatever means.
That being said, my comment was semi tongue-in-cheek
Did not you?
duh, you'd think they could just put it on the calibration scale and leave it there. no need to manipulate it anymore, then.
While that sounds good, it really does not work that way.
There isn't really a 'permission granting' step when, say, exploiting some program. You typically 'just' get to run your code in the context of the exploited program. No permissions 'become available' or 'get lost' in the process, at least as far as the OS can tell.
Now if the vulnerability is know, you could program something like that around it -- but then you could just fix the vulnerability in the first place
Oh, yes, it's not like any program is ever dealt with on the user level, with multiple interactions along the way. Literally everything is a shell script. I had forgotten.
Bit of a weird assumption that only shell script execution would yield an exit status when every program (actually: every process, even on Windows, which you're obviously using) does that.
As to what programs, any number of web apps are an easy example.
Gosh...
I forget what slashdot uses as it's message, but when I'm done and hit submit, I'll see an informative message.
Now this isn't even true, and I'm pretty sure you felt quite stupid after submitting. /. is your comment actually showing up, that's it.
The 'success message' you get from
No it's redundant because the information is already conveyed via the program's exit status.
Besides, you forgot to mention what (relevant) program farts out that particular message, I can't think of any.
So says the guy that doesn't even have enough balls to post anonymously on an internet site.
-anonymous
Only by stupid programs which don't follow the golden rule of shutting the hell up as long as nothing goes wrong.
Therefore you're much more likely to see a message reading "Permission denied", if anything
Let me guess, you consider yourself among the remaining 1%.
then it's the median, but hey, let's try it:
{1, 2, 8, 8, 8, 8, 9, 9, 9, 10, 10}
2/11 (~18%) are smaller than the median.
5/11 (~45%) are larger than the median.
so you're wrong while you're wrong.
arrays and pointers are not 'slightly different'. I replied in detail somewhere else in the thread, if you care about details.
I just saw this grossly wrong claim and since it was AC's i didn't bother to come up with a detailed explanation on why exactly it is wrong, but I didn't want it to become +5 Informative either. A likely thing to happen it seems.
Since some more people asked or complainedI did reply, dear AC
int array[32];
and
int* blah = &(array[0]);
will both point to the exact same element in memory.
``array'' doesn't point anywhere, it's an object in memory of size (32*sizeof (int)) and of type int[32]. [yes, C does have objects.]
``blah'' is another object, of size (sizeof (int*)) and of type int*
Obviously these two things are not remotely "the same" (this was the original claim(*)).
With this out of the way:
If you do an equivalence operator on them, they'll be equal.
In fact (array == blah) will be true in this case, but this is only because there is syntactic sugar involved, and the actual comparison done is (&array[0] == blah).
*(int*)((int)blah+(3*sizeof(int)))
No, this is utter gibberish, and even if some implementation choses to compile it, there would be undefined behaviour. (Protip: you cannot cast pointer types to integer types, and no don't argue that your implementation allows it, or that "heey, pointers are just integers to on the metal" (protip-inside-protip: there is no metal in the C Abstract Machine) If you go that route, you only demonstrate that you have no idea what C is)
(*) Some more reasons for why 'arrays and pointers are the same' is grossly wrong in C:
1. ``but i can assign an array to a pointer!'' -- try assigning a pointer to an array. /at all/ (no, initialization is not assignment) ...
2. in fact, try assigning an array
3. an array can hold multiple elements, a pointer can hold a memory address
4. in expression context, the array "value" is a pointer to its first element -- if both were the same, that rule would be fairly meaningless.
5.
I love how you add words that absolutely nobody said to prop up your straw man.
Erm that was supposed to be a FTFY kind of reply, if you couldn't tell from the emphasis. It's not a straw-man, it's pointing out the flaw in your plan.
The rest of your comment doesn't really make sense to me, but I lost it at ``MCSE'' anyway.
Spare the reply.
I've never understood the people that try to equate it with a penis thing tho
If affected people were to realize and fully understand it, it wouldn't occur in the first place.
Staff intensive as in 1 guy per such machine that has expert
It does not scale.
Furthermore, depending on the importance of the machine, you might have to have someone around /all/ the time instead of just 9-5, ending you with needing at least 3 guys plus replacement
and won't show up in a pcap.
Wow, by design? -_-
Well since you're probably a 5'11" manlet, I basically agree
Uh. The ambiguity didn't occur to me at all. Reads a bit unnaturally that way, but you're right I should've put a comma there.
Sorry for becoming overly annoyed, pretty glad it turned out to be only a missunderstanding
In C, arrays are really just pointers to the first element
No.
, and array[index] is defined through pointer arithmetic: It just means *(array+index). Addition is commutative, so you could just as well write index[array], because that is defined as *(index+array), which is the same as *(array+index).
Yes.
I'm pretty well-aware of what you can do with opamps and RLC, thanks. Not that you mentioned any RLC in the first place, you also left them out in your price comparison, so why would i assume you did anything more complicated than a buffer?
but even both opamps in some exotic configration don't really match what i was referring to by 'moderately complex system'. two operations are not moderately complex.
Administration of said machine is a staff-intensive mess then.