w0000t
w0000t on Hacker News
What!? Size of the array is always known to the programmer in C. In fact, if the programmer wants to get rid of that information, he/she must deliberately do so. Once one does that, the array becomes useless.
You also haven't explained how would that size information, which we already have, magically solve the problem.
Just a note. The quote
Eiriksmal posted is from the section: Why would I NOT want to use Arch?
In my opinion, if those privacy issues bother you, the first step should be an overview of non-Microsoft operating systems.
Yep, C doesn't define that uintptr_t can be modified and converted back to a pointer. It is only for storage.
Since watching CITIZENFOUR I've always wondered, why would they bother destroying their laptops, since it is so easy to make and conceal a copy of those documents.
All ASCII characters are easily accessible. Your suggestion is a strawman, most coding is in plain text form and is typed.
I did a quick calculation a while back. I don't want to repeat it, since I lost the source, but the conclusion was that typing speed doesn't matter for programmers, since most of the time they actually think, not type. I.e. the bottleneck is information no the input of it.
I also wish C++ had a large Standard library. Including <vector>, just works, you don't even have to think about it. Now imagine doing the same for <sound> or <window>.
And prevent learning?
No, what you need to do, is to learn whatever you enjoy, as much as you want in any direction, but recognize your limited knowledge in the field and act accordingly.
So the sound is completely artificial, constructed by you?
( It is very convincing. )
Actually 'b' is at a completely wrong position( on a ordinary keyboard ). It is inaccessible for both hand, without moving your wrist which causes strain.
I have globally remapped 'b' to the right of 'l'. It feels much better. The old 'b' key is now unused.
I wouldn't call it Ether, since that would imply some absolute reference frame.
Yes, I did. But so far I haven't been regularly checking printf return value. :-(
I wonder if checking the result of every printf or asserting it, depending on the circumstances, would reduce the amount of time spent on writing+debugging the code on the long run.
That sort of thing is actually a completely valid approach.
You made a small mistake, since fprintf and printf call the same underlying code, the error handling should be either log the error in any way still available, and then depending on the design of the whole program, exit or continue. If printf fails you know exactly what is going on or have to exit.
( And printf would be wrapped in a function if you plan to use it repeatedly. )
Thank you. Yes, I meant steganography.
That is not what OP is talking about. You cannot get different information out of the same chunk of encrypted data. That would basically make infinite compression.
What the methods you mentioned are doing, is hiding information in places which are marked as: random data no information here. But in reality there is information there. You then need to have dummy information somewhere else.
Storing the different information in the same place is impossible. You could use stenography but then anyone with access to the program/source will immediately discover the deceit.
You can use what hiq is suggesting, https://news.ycombinator.com/item?id=10097533, but that is a different method.
http://www.dwavesys.com/press-releases/d-wave-systems-breaks...This announcement, claims:
Every additional qubit doubles the search space of the processor. At 1000 qubits, the new processor considers 2^1000 possibilities simultaneously, a search space which dwarfs the 2^512 possibilities available to the 512-qubit D-Wave Two.
Since we still aren't able to factor any large numbers with it, those 2^1000 bits don't really work like they say they do. I'm guessing there are many caveats behind their description.
I would appreciate any explanation from an expert.
The problem is it needs to be applied to every function that returns a value. And I'm pretty sure you can't apply it to C library functions. Gcc seriously needs a global flag for this.
This is also addressed in the article.
Reading the title is not enough, you have to read the article.
You missed this paragraph, which occurs in the first 10% of the article.
The second caveat is that the class of functions which can be approximated in the way described are the continuous functions. If a function is discontinuous, i.e., makes sudden, sharp jumps, then it won't in general be possible to approximate using a neural net.
Can you name the those compilers?
That is a pretty naive point of view. That amount of know-how, and I'm assuming he knows much more that has presented, is normal for someone who has been programming for 15+ years straight.
If you find yourself still seriously programming after a few years, try evaluating this position then.
Very convincing. Just by skimming over the text( finding key phrases and words ), I would be fooled into thinking it is a real Reddit thread. On average, only by reading at least two complete sentences it is possible to determine that the whole thing doesn't make any sense.
Don't you have to spawn at the coordinates 0,0, or at the so called "spawn point". How did you start at 5000+?
I'm assuming you used an offline version.