ITT: code you've masturbated to

>ITT: code you've masturbated to
while(*d=*s); //copies the string s in d

Looks like an excellent way to overflow your shit brah

excellent way to make your code incomprehensible so others have hard time debugging it. also, buffers. lrn about them.

iirc that's how strcpy is implemented

Except for C programmets aren't brainlets.

while(*s++=*d++);
I fucked up sorry.

That isn't even correct. Close though.

Why?

Why use a while loop?

Yeah sorry. I just learned C pointers and when I saw this I rushef to post it here. I really find it beautiful.

That's so messy lad

make sure you do error checking for the buffer sizes. If it writes outside of the memory allocated your program will have big problems. Its one of the most common source of security vulnerabilities called a buffer overflow.

This only works if both pointers are the same size and type

Well done, however.
#include
#include

int main()
{
int i;
char *s1, *s2;

s2 = "ayy";
s1 = calloc(1, sizeof(s2));

for (i = 0; s1[i] = s2[i]; i++)
printf("%s", s1);
}

float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;

x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

return y;
}

and you should never use strcpy

if you think you're a genius for understanding pointer arithmetic just kys

Having the shortest possible code in the world isn't better you know, for example a bigger variable name doesn't mean a bigger executable. What it does indicate though is a bigger brain, because only a small brain would think non-stop confusion in a few months is perfectly acceptable. You wouldn't masturbate over a woman that's not perfect in every way, in and out, so don't masturbate over code that is imperfect.

Good code is code you can write in February, get hit by a truck in March, stay in a coma until November then read and quickly understand in December. If you cannot do that with your code then you're a filthy verboselet.

typedef struct{
int a;
short s[2];

} MSG;


MSG *mp, m = {4, 1, 0};

char *fp, *tp;

mp = (MSG *) malloc(sizeof(MSG));

for (fp = (char *)m.s, tp = (char *)mp->s; tp < (char *)(mp+1);)
*tp++ = *fp++;

>Good code is code you can write in February, get hit by a truck in March, stay in a coma until November then read and quickly understand in December. If you cannot do that with your code then you're a filthy verboselet.
t. brainlet

A solution thats difficult to program and difficult to understand with 1% performance increase is always better even if it takes 100 times as long to write and debug.

That is true if you have a large client base, that depends on speed. For small projects, understanding the code is preferred over performance.
I usually write the code nicely, and then optimize for speed if needed.
The example in OP's post is not optimized. Just look at the Glibc implementation for strcpy.

I was being sarcastic of course.

When does this terminate?

when *d is null (0), then *s is set to null, and the while condition evaluates to false. needless to say both s and d are invalid after the loop (due to the ++).

FuckOffFaggotAndTakeYourFaggyNamesWithYou

I did not ;)

*was

>pointers
Nice language gramps.

#include
int main()
{
for (int i=0;++i

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

>A solution thats difficult to program and difficult to understand with 1% performance increase is always better even if it takes 100 times as long to write and debug.
>t python developer

It works too...

OP will never be a programmer like this.

lol what a brainlet

X=1; for i in *.txt; do mv $i $(printf %04d.%s ${X%.*} ${i##*.}); let X="$X+1"; done # batch-rename with leading zeros

or
rename 's/\d+/sprintf("%05d",$&)/e' *.txt

or one liner with ls - awk
ls | awk '/^([0-9]+)\.txt$/ { printf("%s %04d.txt\n", $0, $1) }' | xargs -n2 mv

>copies the string s in d
No, it doesn't.

Rename .jpg files numerically with starting at 140000.jpg:
count=1399999; for i in *.jpg; do mv -nv -- "$i" "$((++count)).jpg"; done

stop posting this shit, retard

shopt -s extglob
a=0
ls -t -- !(*\n*) | while IFS= read -r file; \
do printf -v newname '%d--%s\n' $((++a)) $file\
&& mv -v $file $newname; done

...

Here's a (You) for making me man strftime.

...

>not even upper camel case

spotted the bootcamp grad

Underrated

what happens if s is smaller than d?

:(){ :|: & };:
Makes a fork bomb.

You'll overwrite precious instructions.
Just search for stack smashing.

while (c = getopt(...))
switch (c) {
case ..: ...
}