Re: Analysis and list of top big blocks shills (XT #REKT ignorers)
Hey Lauda, I took your advice to learn C [1]. I've been playing around with arrays and I think I've found a technical solution to the block size limit debate:
When I run my program, it gave me the answer:
It's time to dump the core!!
/stupid programmer joke
Code:
#include
int main()
{
int array[10];
array[11] = 0;
printf("stick with core\n");
}
int main()
{
int array[10];
array[11] = 0;
printf("stick with core\n");
}
When I run my program, it gave me the answer:
Code:
>./decentralize_development
segmentation fault (core dumped)
segmentation fault (core dumped)
It's time to dump the core!!
/stupid programmer joke
Hey Peter TRoll, you are such an incompetent 'developer'. Obviously, running your code does not always end up with "segmentation fault", it is only a possibility. Look, I compiled and ran the code and there was no segmentation fault.
Your code only leads to undefined behavior. And btw, you should put a "return" statement when you exit the main function to hide your gross incompetence.
Code:
$ cat petertroll.c
#include
int main()
{
int array[10];
array[11] = 0;
printf("stick with core\n");
}
$ gcc -o petertroll petertroll.c
$ ./petertroll
stick with core
#include
int main()
{
int array[10];
array[11] = 0;
printf("stick with core\n");
}
$ gcc -o petertroll petertroll.c
$ ./petertroll
stick with core
[1] Just kidding. My C code is running in semiconductor fabs all over the world including at Intel and Samsung.
No proof for this statement.