/prog/ - Go — World4ch

Name: Anonymous 2012-06-23 6:16

Currently running this bitch on a server with 24 processors clocked at 2.6Ghz, 16GB of ram and fiber connection. Currently pinging about 300-400 IP addresses/second. And the glue holding this bitch together is Go. Look at that simple concurrency model and message passing, it's a thing of fucking beauty. Now to get this running on the other 4 servers just like it.

http://pastebin.com/rqEvpszX
Currently running at: 177 valid IPs/second, 582 IPs/second

And I know that the last part is a little hacky and that the IP functions should be moved to their own source file. Bite me.

Why aren't you using Go /prog/?

Name: Anonymous 2012-06-23 16:41

Can you name a language meant to replace C that isn't actually worse?

Name: Anonymous 2012-06-23 16:43

>>30
No. All of the better languages weren't created with C in mind at all.

Name: Anonymous 2012-06-23 16:45

>>21
Which is stupidly easy in C:

int32_t foo;

uint8_t foo_0 = ((int32_t*)foo)[0];

/* ... */

Name: Anonymous 2012-06-23 16:56

>>32
No. The cast should be (uint8_t*) but even then it's undefined behaviour.

Name: Anonymous 2012-06-23 17:15

>>33
It should be uint8_t, you're right, but why is it undefined? Endianness?

Name: Anonymous 2012-06-23 17:16

>>33
Only with strict aliasing rules, although you could effectively circumvent those with:

union {

    uint32_t u32;

    uint8_t u8[4];

} ip;

There's still the matter of endianness, however for this particular program that's utterly irrelevant.

Name: Anonymous 2012-06-23 17:21

>>35
IIRC casting a pointer into a pointer on an incompatible type is undefined behaviour.

Name: 36 2012-06-23 17:23

By the way, using a union as you suggest is also undefined behaviour. The contents of a field of a union become undefined after writing to another field.

Name: Anonymous 2012-06-23 17:24

uint8_t foo_0 = ((int8_t *)foo)[0];
is perfectly fine, and since it's the first byte:
uint8_t foo_0 = (int8_t *)foo;

_{_{_{neverminding endianness}}}

Name: Anonymous 2012-06-23 17:24

>>36
It's not, however C's strict aliasing rule states that no two types must alias the same memory. If you were to compile that with gcc -fstrict-aliasing, the resulting code would probably fail.

Name: Anonymous 2012-06-23 17:28

>>37
that's not exactly true either, quoting the K&R:
the results are implementation-dependent if something is stored as one type and extracted as another.
page 148, 2nd Edition

Name: Anonymous 2012-06-23 17:32

>>37
You sure about that? I thought that the fields of a union had to occupy the same region of memory, which would be the size of the largest field (so a union { uint64_t u64; int32_t i32; }; would be 8 bytes).

Name: Anonymous 2012-06-23 17:36

>>41
As a sidenote: The size occupied by a symbol in memory is not necessarily the minimum size possible, for optimization issues.

Name: Anonymous 2012-06-23 17:38

>>37,41
I suppose that if the union was volatile it would be required to actually update the field, but there's still endianness, padding bits, and integer representations to worry about.

Name: Anonymous 2012-06-23 17:38

The standard doesn't say anything about the exact encoding of data. It is implementation-dependent.

Name: Anonymous 2012-06-23 17:42

>>43
volatile has nothing to do with this...

Name: Anonymous 2012-06-23 18:19

And this thread has officially devolved into a C pissing match.

Name: Anonymous 2012-06-23 18:21

>>37,41,43
It doesn't matter if it's volatile or not, they do overlap in size but after writing to one field it is undefined behavior to read from another.

Name: Anonymous 2012-06-23 18:28

>>46
This is hardly a pissing contest, it's just people who don't know the basics of C and some who do.

Name: Anonymous 2012-06-23 18:36

>>45
Yes it does. It ensures that the memory is actually written to.

union {

    char c;

    unsigned char u;

} u;

volatile union {

    char c;

    unsigned char u;

} vu;

u.c = 10; /* may be stored in a register or optimized away */

printf("%u", (unsigned)u.u); /* accessing u.u is undefined behavior */

vu.c = 10; /* must be written to memory */

printf("%u", (unsigned)vu.u); /* vu.u is guaranteed to contain 10 */

Name: Anonymous 2012-06-23 18:45

>>49
but that's just plain wrong... volatile ensures the memory is read, not written, because it warns the compiler that there might be code that is doesn't know about that also uses that memory address

in your example u.c = 10; can surely be optimized but only if the other symbol is not used like you do just after, decent compilers aren't that stupid yet, if u.c = 10; is optimized then u.u will use the same register

but go ahead test it, gcc -O3 that code and see for yourself

Name: Anonymous 2012-06-23 19:49

Hey, look at how many C caveats I have memorized! This is truly the language of the Gods!! Am I an ^EXPERT _PROGRAMMER yet?

Name: Anonymous 2012-06-23 20:01

>>51
Not unless you can't actually use even one of them to construct an elegant algorithm.

Name: Anonymous 2012-06-23 20:36

>>39
IIRC type punning like that is undefined.

Name: Anonymous 2012-06-24 5:34

>>49
It is still undefined behavior to write to the c field and then read from the u field. This is very clear in the standard and it's quite obvious as well considering how many different types of architectures there are out there.

Name: Anonymous 2012-06-24 6:21

>>56
Read the footnote for 6.5.2.3 point 3, C99 TC3 or C11.

Name: Anonymous 2012-06-24 10:18

>>57
Do you even know what a trap representation is? Honest to god I can't believe how unbelievably slow some people on /prog/ are, that very footnote specifically states that the value is unspecified and therefore the program contains undefined behavior.

Name: Anonymous 2012-06-24 10:20

>>60
s/unspecified/indeterminate/

Name: Anonymous 2012-06-24 11:35

>>60
unsigned char has no trap representations that produce undefined behaviour.

Go

1 Name: Anonymous 2012-06-23 6:16

30 Name: Anonymous 2012-06-23 16:41

31 Name: Anonymous 2012-06-23 16:43

32 Name: Anonymous 2012-06-23 16:45

33 Name: Anonymous 2012-06-23 16:56

34 Name: Anonymous 2012-06-23 17:15

35 Name: Anonymous 2012-06-23 17:16

36 Name: Anonymous 2012-06-23 17:21

37 Name: 36 2012-06-23 17:23

38 Name: Anonymous 2012-06-23 17:24

39 Name: Anonymous 2012-06-23 17:24

40 Name: Anonymous 2012-06-23 17:28

41 Name: Anonymous 2012-06-23 17:32

42 Name: Anonymous 2012-06-23 17:36

43 Name: Anonymous 2012-06-23 17:38

44 Name: Anonymous 2012-06-23 17:38

45 Name: Anonymous 2012-06-23 17:42

46 Name: Anonymous 2012-06-23 18:19

47 Name: Anonymous 2012-06-23 18:21

48 Name: Anonymous 2012-06-23 18:28

49 Name: Anonymous 2012-06-23 18:36

50 Name: Anonymous 2012-06-23 18:45

51 Name: Anonymous 2012-06-23 19:49

52 Name: Anonymous 2012-06-23 20:01

53 Name: Anonymous 2012-06-23 20:36

56 Name: Anonymous 2012-06-24 5:34

57 Name: Anonymous 2012-06-24 6:21

60 Name: Anonymous 2012-06-24 10:18

61 Name: Anonymous 2012-06-24 10:20

62 Name: Anonymous 2012-06-24 11:35

Name: Anonymous 2012-06-23 6:16

Name: Anonymous 2012-06-23 16:41

Name: Anonymous 2012-06-23 16:43

Name: Anonymous 2012-06-23 16:45

Name: Anonymous 2012-06-23 16:56

Name: Anonymous 2012-06-23 17:15

Name: Anonymous 2012-06-23 17:16

Name: Anonymous 2012-06-23 17:21

Name: 36 2012-06-23 17:23

Name: Anonymous 2012-06-23 17:24

Name: Anonymous 2012-06-23 17:24

Name: Anonymous 2012-06-23 17:28

Name: Anonymous 2012-06-23 17:32

Name: Anonymous 2012-06-23 17:36

Name: Anonymous 2012-06-23 17:38

Name: Anonymous 2012-06-23 17:38

Name: Anonymous 2012-06-23 17:42

Name: Anonymous 2012-06-23 18:19

Name: Anonymous 2012-06-23 18:21

Name: Anonymous 2012-06-23 18:28

Name: Anonymous 2012-06-23 18:36

Name: Anonymous 2012-06-23 18:45

Name: Anonymous 2012-06-23 19:49

Name: Anonymous 2012-06-23 20:01

Name: Anonymous 2012-06-23 20:36

Name: Anonymous 2012-06-24 5:34

Name: Anonymous 2012-06-24 6:21

Name: Anonymous 2012-06-24 10:18

Name: Anonymous 2012-06-24 10:20

Name: Anonymous 2012-06-24 11:35