Why making threads like this? The ones who are valuable know about it for years, trolls are not welcome. Also, when I needed the C channel, I just /join'ed c, server redirected me to ##C and that's it. No need to advertise it, the ones who need will find it anyway.
<larmeh_> i know it's probably up to the programmer whether or not to use malloc().. but when is it usually a good idea _not_ to use it?
<hellyeah> hey
<hellyeah> c has a api just like java
<hellyeah> because i see lots of function like strcmp, strlen
<hellyeah> i said to myself if it is c has a api it would be good
Zhivago is the ultimate troll. It's the only reason I idle there. Otherwise, I stick to a smaller C++ channel on a smaller network, which has an actual community more akin to /prog/
Name:
Anonymous2009-11-08 19:40
wow.
these guys don't seem to know shit
Name:
Anonymous2009-11-11 8:37
Seriously, just say ANYTHING in this channel and the regulars (the informed half, not the completely retarded half) will jump down your ass and snark you to death
>>15
Well, I was lurking #4chan for a few days recently, until I was banned without ever having said a word.
That's IRC QUALITY for you. Everyone is an asshole there.
Name:
Anonymous2009-11-11 9:01
>>17
wow you must be some seriously sweaty slab of fail for that to happen. I've never been banned and I lurk/comment all the time, don't blame irc for your epic amount f fail
>>29
Yes, indeed, the IDE fence values will always be there and... oh. Wait a minute, a character could take the value of a fence. What will we do!
Name:
Anonymous2009-11-21 17:04
<bros> kate`: How can I get 3,000 hexadecimal bytes into memory?
<neil127> they are stored in a file in hexadecimal format?
<kate`> bros, what's a hexadecimal byte?
<bros> 0s and 1s.
Name:
Anonymous2009-11-21 18:57
From a Jew's face
The wicked Devil speaks to us,
The Devil who, in every country,
Is known as an evil plague.
Would we from the Jew be free,
Again be cheeful and happy,
Then must youth fight with us
To get rid of the Jewish Devil.
>>17
Really? I don't talk much on #4chan either, but I was never banned from there. Quite a lot of people lurk on that channel and almost never speak and yet they do not get banned. You must have done something or said something to piss one the OPs off.
Name:
Anonymous2009-11-22 2:59
>>27
Yeah, and those filters and such are for curbing the amount of worthless and stupid /b/-esque crap that finds its way in somehow. It's quite understandable why the OP does that, otherwise the channel would devolve into /b/ - real time chat.
>>38
Sure, the morons who find their way in there when the OPs aren't around. There's also a fine gentleman who occasionally sacrifices his other nick to forcefully get an offending idiot g-lined.
Name:
The joys of !!37LUkM96nRgDQXR2009-12-07 5:02
<pozic> How can I set the last element of an array of structs foo{int a;double b;} to NULL? If I just set it to NULL, I get incompatible types.
<apples`> you can't
<apples`> (as you have found)
<pozic> apples`: how can you find/set "the end" of an array then?
<twkm> NULL is for pointer values. you have none present.
<pozic> If I turn the struct into a union, will it work then?
Name:
Anonymous2009-12-07 5:39
This is from last night:
[01:26:24] <convivial> Hello.
[01:26:26] <convivial> question.
[01:26:42] <convivial> & operator actually takes offset of variable and not true address
[01:27:22] <convivial> the reaason I think is because code can be relocated by OS there, if & took physical address at some point in program address would be invalid
[01:27:38] <convivial> thus,& is actually get memory offset of not address of
[01:28:47] <twkm> how the & prefix operator is implemented is, well, an implementation detail.
[01:28:58] <twkm> why do you care if it is the "true" address?
[01:29:55] <Oddity> Look-up "logical address". And I don't really see a question anywhere.
[01:30:05] <convivial> well, sometimes you want physical address rather than logical
[01:30:25] <convivial> question is, how does one get true physics address?
[01:30:31] <convivial> of like port?
[01:30:39] <spv> that's got nothing to do with C really, it's your implementation.
[01:30:40] <twkm> what if such things don't exist?
[01:31:10] <convivial> C has to provide a way to get physical addresses
[01:31:22] <Peaker> convivial: why?
[01:31:41] <convivial> how does one access ports then?
[01:32:08] <twkm> if such things exist, you using o/s specific facilities.
[01:32:14] <Peaker> convivial: with implementation-specific libraries provided by the platform/etc
[01:32:57] <Oddity> C doesn't provide you with many things.
[01:33:16] <convivial> ok.
[01:33:35] <tdmackey> yeah, it is something the operating system or hardware specific driver would provide c bindings for, but c by itself does not provide something
[01:33:36] <convivial> I guess the best way if to get access to Ring 0 of processor, (intel), and set data segment at 0.
[01:33:47] <twkm> sigh.
[01:35:24] <convivial> hmmm...
[01:35:46] <convivial> ok, then ... I just curious, it just popped into my head one night when i was thinking about pointers.
[01:35:55] <convivial> yeah, i guess the OS would provide that
[01:37:25] <convivial> but, i feel that offset is better term than address, because in todays world , you're dealling with multiprocess os's, even most embedded thus you'll never get a true address with '&' operator
[01:38:04] <convivial> only it's offset within the data segment, however that may be defined per CPU/OS
[01:38:46] <convivial> it may confuse students learning C and OS design at same time I bet.
[01:39:01] <melba> didn't confuse me
[01:39:02] <twkm> uh-huh.
[01:39:28] <convivial> me either but I can from world of 8bit asm, must students dont have that background
[01:39:48] <tdmackey> most students don't jump in from no knowledge to core OS design
[01:39:51] <spv> convivial: C doesn't define things such as data segments, so why would it even be relevant?
[01:40:12] <convivial> spv: that was not the mainpoint
[01:40:22] <convivial> spv: my point is that & is not returning addresses
[01:40:37] <spv> sure it is
[01:40:38] <Oddity> It returns the logical address of the variable.
[01:40:43] <tdmackey> and you aren't going to change a term that has been used in such a way since the early 70s
[01:40:56] <convivial> in fact, (*ptr)() and &a could have same value
[01:41:16] <Oddity> Maybe you should go back to studying.
[01:41:21] <Oddity> Study memory models or something.
[01:41:28] <spv> study the C standard
[01:41:35] <Oddity> that too
[01:41:53] <convivial> given, void (*ptr)() = printf; and int a;
[01:42:02] <Zhivago> convivial: You do not understand what address means, then.
[01:42:14] <Zhivago> convivial: Also, you might be confused about what 'offset' means.
[01:42:23] <Zhivago> convivial: int a; What is the 'offset' of a?
[01:42:23] <convivial> an address is location in memory
[01:42:39] <convivial> offset is displacement from base address
[01:42:43] <tdmackey> an absolute address uniquely identifies a location in memory, but a relative address does not
[01:42:44] <Zhivago> convivial: What base address?
[01:42:57] <convivial> base address is defined by OS
[01:43:03] <Zhivago> What base address i nC?
[01:43:04] <convivial> it is the address of code or data segemtns
[01:43:11] <Zhivago> What code or data segment in C?
[01:43:26] <convivial> come on now,
[01:43:36] <convivial> you know that eventually you get linked
[01:43:38] <Zhivago> Ah, you don't know ...
[01:43:44] <Zhivago> There are no base addresses in C.
[01:43:49] <Zhivago> There are no code or data segments in C.
[01:43:57] <Zhivago> And this is why you do not understand these terms properly.
[01:43:59] <convivial> Not in C per se, but the linked code it is.
[01:44:05] <Zhivago> An address is a means by which you can find an object.
[01:44:11] <Zhivago> This is precisely what &a gives you.
[01:44:17] <convivial> C does not have object's
[01:44:17] <Zhivago> *&a being the object a.
[01:44:27] <convivial> you're confused with java or c#
[01:44:30] <Zhivago> C has objects -- read the C specification.
[01:44:31] <spv> convivial: yes it does.
[01:44:36] <Oddity> HAHA\
[01:44:37] <convivial> C has data types
[01:44:37] <spv> convivial: int a; a is an object.
[01:44:59] <convivial> and aggregates
[01:45:01] <Zhivago> C has data types, which may be objects or values.
[01:45:34] <convivial> C has primitive types, aggregates
[01:45:41] <Zhivago> convivial: That is irrelevant.
[01:45:53] <convivial> aggregates include arrays, structs,
[01:45:59] <Zhivago> convivial: Again, irrelevant to objects.
[01:46:08] <convivial> primitives are integral types
[01:46:11] <Zhivago> convivial: int a; <- a is an object of type int.
[01:46:28] <Zhivago> convivial: a + 1 <- this is an expression producing a value of type int.
[01:46:29] <convivial> ok, call it object.
[01:46:38] <Zhivago> Yes, I will -- just like the C specification does.
[01:46:59] <convivial> I['m going to submit they change it
[01:47:00] <Peaker> Zhivago: that's often termed "lvalue" and "rvalue", no?
[01:47:05] <spv> convivial: want to know what the standard defines as an object? "region of data storage in the execution environment, the contents of which can represent values"
[01:47:17] <convivial> and gopiikng to submit they change address to offset
[01:47:36] <Zhivago> Peaker: As the C standard notes, those are better termed "object" and "value".
[01:47:55] <Zhivago> Peaker: Particularly since lvalue and rvalue are meaningless gibberish.
[01:48:19] <Zhivago> Also, it doesn't address the issue of what objects are -- an lvalue is how an object can be used.
[01:48:21] <tdmackey> convivial: learn the terms as they stand instead of fighting a community of programmers than has been using them since 1972
[01:48:24] <spv> I'm sure the C standards committee would love to hear your suggestion that they change the definition.
[01:49:12] <Oddity> must be a troll...
[01:49:21] <convivial> I'm just being architecturally correct
[01:49:24] <convivial> that's all.
[01:49:33] <Zhivago> convivial: No, you are being architecturally incorrect.
[01:49:34] <convivial> I know what we call them in asm
[01:49:41] <Zhivago> convivial: Asm isn't C.
[01:49:51] <tdmackey> convivial: you are being ignorant and interweaving hardware programming and C
[01:49:54] <Zhivago> convivial: The correct architecture for C is the C Abstract Machine.
[01:50:06] <convivial> ok.
[01:50:11] <Zhivago> convivial: Stop confusing asm with C and you'll start to understand C, which has a very different model.
[01:50:34] <convivial> I will stick to strict C99 terminology then...
[01:51:00] <Zhivago> int a; int b; What is &a - &b?
[01:51:18] <convivial> Zhivago: that is unknown
[01:51:35] <Zhivago> No, it's incorrect.
[01:51:47] <convivial> it will be the difference betwenen offsets
[01:51:48] <Zhivago> You may not subtract pointers that point into different vectors of objects.
[01:51:57] <Zhivago> No, you are wrong. There is no offsets here.
[01:52:01] <convivial> but the value i can't say
[01:52:07] <Zhivago> The objects a and b are not in the same memory space.
[01:52:16] <Zhivago> C does not have a flat memory model.
[01:52:24] <convivial> they are local stack vars
[01:52:30] <Zhivago> There is no stack in C.
[01:53:05] <convivial> void FU(){int a; int b; } here a and b are not in same place?
[01:53:11] <Zhivago> No.
[01:53:19] <Zhivago> They are completely discrete allocations.
[01:53:35] <Zhivago> Which is why you cannot say &a - &b
[01:53:48] <convivial> how is that?
[01:53:56] <Zhivago> By definition.
[01:53:58] <convivial> push allocate off stack
[01:54:04] <Zhivago> There is no stack in C.
[01:54:13] <Zhivago> Pointers in C are not offsets from some base address.
[01:54:13] <tdmackey> you are confusing what the system does and what C is.
[01:54:21] <Zhivago> A pointer in C is an index into a vector of objects.
[01:54:30] <Zhivago> In this case you have two separate vectors of one int each.
[01:54:58] <Zhivago> The indexes between two different vectors of objects are obviously not comparable, so ...
[01:55:18] <convivial> well, that is kind of dumb but also you're question is convenient because &a - &b has no application in context you specified.
[01:55:27] <convivial> *your
[01:55:40] <Zhivago> It has no application anywhere.
[01:55:44] <Zhivago> This is because it is inapplicable.
[01:55:47] <convivial> I see no reason to do that in first place.
[01:56:13] <Zhivago> What it illustrates is that your notion of 'offsets' is completely wrong.
[01:56:16] <convivial> unless &st.a - &st.b, that makes sense]
[01:56:21] <tdmackey> he is trying to get the point across that C has nothing to do with the underlying system architecture
[01:56:47] <convivial> well, ok. ok.
[01:56:55] <tdmackey> and all you are recalling is your experience with asm
[01:56:58] <convivial> I accept that and move on.
[01:57:02] <trijezdci> it would be misleading to say "there is no stack in C", instead if would be preferable to convey the intended meaning by saying "there is no stack in C terminology"
[01:57:17] <Zhivago> tri: No, it is correct to say that there is no stack in C.
[01:57:17] <tdmackey> which is blurring your understanding of C
[01:57:34] <trijezdci> no, it refers to terminology
[01:57:35] <Zhivago> tri: A C implementation might use a stack to implement auto storage, or it might not.
[01:57:42] <Zhivago> tri: No, it refers to the specification of the language.
[01:57:56] <trijezdci> you are confused what a stack is though
[01:58:07] * DaZ_ is now known as DaZ
[01:58:07] <Zhivago> No, I am not.
[01:58:14] <trijezdci> any storage that satisfies lifo semantics can be referred to as a stack
[01:58:16] <convivial> i've been away from C for 6years
[01:58:16] * PureSine_ is now known as PureSine
[01:58:27] <convivial> guess I should reread C99 spec from page 1 to end
[01:58:28] <Zhivago> tri: And C has no such storage.
[01:58:48] <tdmackey> A stack is a datastructure that C can implement, or that is used by the underlying system as a means of storage but C itself does not provide it
[01:58:54] <convivial> ~C99
[01:59:00] <convivial> !C99
[01:59:01] * candide blinks.
[01:59:03] <trijezdci> you need lifo semantics
[01:59:06] <convivial> you guys dont have bots?
[01:59:07] <Zhivago> Which means that there is no stack in C.
[01:59:12] <spv> convivial: yes.
[01:59:12] <convivial> topci
[01:59:14] <Zhivago> No, C doesn't need lifo semantics.
[01:59:27] <convivial> got it in topic
[01:59:34] <convivial> well i'm off to read up
[01:59:35] <spv> !standard convivial
[01:59:36] <candide> convivial: C99 + TC1,2,3 working paper: http://open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf - Quick C library reference: http://www.acm.uiuc.edu/webmonkeys/book/c_guide/ - An explanation of all C standards: http://clc-wiki.net/wiki/The_C_Standard
[01:59:37] <convivial> thakks
[01:59:39] <trijezdci> you need lifo semantics when means you need a stack to *implement* it
[01:59:40] <Zhivago> C only needs to be able to manage the dynamic extent of auto storage objects within blocks.
[01:59:45] <trijezdci> which*
[01:59:51] <Zhivago> There is no part of C that requires lifo semantics.
[01:59:57] <tdmackey> why do I need lifo semantics?
[02:00:02] <trijezdci> you could use a heap to implement your lifo semantics
[02:00:09] <trijezdci> and that would then qualify as a stack
[02:00:17] <Zhivago> tri: There are no lifo semantics.
[02:00:20] <trijezdci> even though its not the machine stack most implementation do use
[02:00:35] <tdmackey> once again, C, the language, doesn't know or care
[02:00:46] <Zhivago> tri: Consider { int i; int j; ... } What order do i and j get deallocated in?
[02:00:48] <trijezdci> lifo => last in - first out
[02:00:55] <Zhivago> tri: Yes, so answer my question.
[02:01:16] <trijezdci> allocation matters not
[02:01:18] <trijezdci> access matters
[02:01:31] <Zhivago> tri: Uh, so what part of C do you think you're referring to here?
[02:01:55] <trijezdci> without lifo semantics in your storage implementation you cannot do recursion
[02:02:03] <trijezdci> C explicitly supports recursion
[02:02:13] <Zhivago> tri: What does recursion have to do with stacks?
[02:02:43] <trijezdci> stacks are the common term used for storage implementations that satisfy lifo
[02:02:56] <Zhivago> So what?
[02:03:07] <Zhivago> There is no implementation in C.
[02:03:11] <trijezdci> it encompasses a wider range that the machine stacks you have on most CPUs
[02:03:11] <tdmackey> C doesn't care about implementation
[02:03:13] <Zhivago> You are confusing compilers with the language.
[02:03:19] <Raiford> this discussion is recursive
[02:03:19] <Zhivago> So stop babbling and stop doing that.
[02:03:25] <trijezdci> no I don't, you are
[02:03:47] <trijezdci> its a matter of terminology
[02:03:49] <tdmackey> C has no knowledge of the underlying system or how the language is implemented
[02:03:54] <Zhivago> tri: No, it's a matter of semantics.
[02:04:04] <Zhivago> tri: There is no part of the C specification that requires stacks.
[02:04:09] <Zhivago> tri: So stacks aren't part of C.
[02:04:14] <trijezdci> there is implicitly
[02:04:19] <Zhivago> tri: You're talking about implememtations, and that's irrelevant.
[02:04:19] <trijezdci> C requires the support of recursion
[02:04:24] <trijezdci> recursion requires lifo
[02:04:27] <Zhivago> tri: Recursion doesn't require stacks.
[02:04:29] <Zhivago> tri: Wrong.
[02:04:29] <trijezdci> lifo means stack
[02:04:33] <Zhivago> tri: Wrong.
[02:04:40] <Zhivago> tri: Do you understand CPS?
[02:04:45] <trijezdci> evn if you don't use a machine stack to implement your lfio
[02:04:54] <trijezdci> it will still qualify to be called a stack
[02:04:57] <Zhivago> tri: Do you understand CPS?
[02:05:31] <Zhivago> tri: If you don't, then it will make understanding longjmp harder.
[02:05:32] <melba> don't google it
[02:05:39] <Zhivago> Nothing wrong with googling it.
[02:05:53] <trijezdci> you are missing the issue here
[02:06:03] <trijezdci> a stack is not what you think it is
[02:06:07] <Zhivago> tri: The issue that recursion doesn't require stack semantics?
[02:06:08] <trijezdci> a stack is ANYTHING that does lifo
[02:06:10] <trijezdci> anything
[02:06:14] <trijezdci> no matter how you impement
[02:06:16] <Zhivago> tri: Yes, and recursion doesn't do lifo.
[02:06:21] <Oddity> Google doesn't give much help
[02:06:27] <Zhivago> tri: The problem is that you don't understand recursion.
[02:06:29] * SiegeX wants to know wht CPS is
[02:06:33] <trijezdci> read Grune
[02:06:45] <Zhivago> siege: Continuation Passing Style.
[02:06:50] <trijezdci> there is a proof somewhere that recursion requires lifo
[02:06:59] <trijezdci> somewhere in Grune's papers
[02:07:00] <Zhivago> tri: And it is wrong.
[02:07:30] <Zhivago> tri: Do you know what a continuation is?
[02:07:43] <trijezdci> yeah right, perpetual motion machines are also possible, proof to the contrary are wrong
[02:08:17] <Zhivago> tri: Do you understand how to do recursion without returns?
[02:09:15] <trijezdci> I go by the scholars that have published papers on the matter over IRC wisdom of crowds
[02:09:36] <Zhivago> tri: So, that's a "no," then?
[02:09:58] <tdmackey> trijezdci: then read AI Memo 349 by Sussman and Steele if you care about scholars
[02:10:07] <Raiford> trijezdci, are you suggesting there are no scholars in channel ?
[02:10:11] <Zhivago> tri: Do you think that a recursive call needs to return?
[02:10:17] <trijezdci> I have written a compiler that implements coroutines natively, I know what you refer to, but it has no bearing on the issue
[02:10:28] <Zhivago> tri: Do you think that a recursive call needs to return?
[02:12:35] <tdmackey> heh
[02:12:36] <Oddity> He is deeply contemplating the matter
[02:12:40] <Zhivago> Peaker: See what "appeal to authority" does to peoples' brains.
[02:12:59] <Zhivago> Thinking is always good.
[02:13:32] <tdmackey> indeed
[02:14:30] <Oddity> <trijezdci> I am not contemplating anything, I find it incredibly laughable how C folks ride on their terminology and do not accept that there are alternative definitions of the terms they consider absolute, alternative definitions that are widely accepted outside of C circles
[02:14:35] <Oddity> ps. don't PM me
[02:15:13] <Zhivago> Well, that's stupid people for you;.
[02:15:30] <Zhivago> Always first concerned with protecting their stupidity.
>>52
I like listening to Zhivago and twkm both. It's always fun when they explain shit to someone who is extremely dumb and/or argues about points that they are obviously wrong about.
Name:
Anonymous2009-12-08 5:20
I used to go on #c yeeears ago... like 7 years ...and i remember his name from then
Name:
Anonymous2009-12-08 13:05
>>53
They're pretty much the ultimate reverse trolls. I love the degree to which they try to demean people in the channel.
>>52
True dat, kate is a little doll. Had me a PM about compiler theory with "her" once. I bet it's what sex is like.
Name:
Anonymous2009-12-08 19:22
Zhivago is not even right. C has not stack, what>?
>>56
He's just talking about the C standard.
It's like how the standard leaves such issues open. In practice, the stack almost always exists, but the standard doesn't require it to exist, and you can implement a compiler which doesn't use a stack, however in practice there will almost always be a stack.
So it's the old: Standard vs Implementation issue.
It's right to say: Microsoft's Optimizing C compiler uses the stack to implement function calls.
It's wrong to say: The C language (and standard) requires a stack be used to implement function calls.
When someone makes use of the stack construct or knowledge of the layout of some structures in memory, then they can no longer say they're just programming in C, they have to say they're programming for a specific implementation, such as GCC or MSVC or ICC or whatever.
This can be generalized to many other languages which have formal standards and many implementations. Standards leave many things open/implementation dependent/undefined. Things which become defined once implemented, but once you make use of such defined things, you're no longer programming in the language defined in the standard, but in some specific implementations of the language. If your code covers most popular implementations, you could say that it's even de-facto portable, even though, not portable by the definition of the standard, but that doesn't bear much practical meaning.
To elaborate on the issue some more, in C you have variable-argument lists, and you have the macros va_start/va_end/va_arg. They let you work with variable numbers of arguments. In practice, they're usually implemented as some macros which do some trivial pointer arithmethic on the stack (if the implementation uses a stack), but that requires the implementor of those macros (and probably compiler writer) to know how the compiler implements parameter passing. In some strange implementation of C, you could implement argument passing through CPS, or passing consed up lists or whatever, and the implementations of va_start/va_end/va_arg would differ, but if the implementation is standards compliant and the code is valid, portable C, then it will work just fine, as long as you don't assume things about memory layouts yourself.
Here's another example from another language:
The Common Lisp standard does not require tail-recursion optimization in implementations. Almost all serious implementations do perform this optimization. Scheme requires TCO.
It may be said that using tail-recursion to implement looping in Lisp is a bad idea as the standard leaves it open for implementations to break such functions, however in practice almost all implementations will let you write proper tail-recursive functions. The de-facto standard where almost all implementations perform this optimization means you can write such functions safely, even though the standard says that implementations aren't required to do it.
(This doesn't mean I'm a huge fan of tail-recursion for emulating iteration - I just use the proper iteration constructions most of the time.
It was just an example of a common point of debate.)
>>59
This is off-topic but nothing new there, but looping is not the only use for TCO (the canonical example being state machines). I'm guessing you already know that, but the belief that TCO is only for functional loops is the reason why we have certain BDFLs claiming that they are useless and training new generations of smug python weenies into the cult of there should be one, obvious way and one way only
<camcorder> why not use strstr
<Zhivago> Why not just iterate the string, accumulating?
<camcorder> while ((k = strstr ("text", "c") != NULL) { i++; }
<Zhivago> Well, that isn't going to work.
<camcorder> Zhivago, why?
<Zhivago> Because it is complete gibberish.
<Zhivago> What is the value that you are assigning to k?
<camcorder> s/"text"/k/ then
<Zhivago> cam: Wouldn't help.
<Zhivago> cam: Also you didn't answer my question.
<camcorder> Zhivago, k is the pointer to the "c" ?
<Zhivago> cam: You're not assigning a pointer value to k ...
<camcorder> Zhivago, ah, that was code part, it should char *k = "text"; ((k = strstr (k, "c") != NULL) { i++; }
<Zhivago> cam: Syntax error.
<camcorder> maybe having *k++ inside the while loop is helpful :P
<Zhivago> No.
<Zhivago> Sit down, shut up and think.
<camcorder> ok again: char *k = "text"; while ((k = strstr (k, "c") != NULL) { *k++; i++; }
<Zhivago> cam: What value are you assigning to k?
<Peaker> camcorder: why *k++ and not k++ ?
<Zhivago> Because he's guessing like a moron rather than thinking.
<camcorder> Zhivago, if you have some personal problems, you can try to solve it somewhere else, like at a psychic's office
>>44-46
I'm confused, are both convivial and Zhivago trolls?
Also, am I right in assuming that by C does not have a flat memory model.
he means that C doesn't really have any specific memory model?
Name:
Anonymous2009-12-22 14:41
>>69
Zhivago is one of the mods in ##C who shows up to assist retarded people in solving their problems.
convivial is one of these extraordinarily stupid people who doesn't understand anything about computers.
he means that C doesn't really have any specific memory model?
of course
Name:
Anonymous2010-01-14 1:02
Well , it looks like n00p has been burrying his face very deep in Zhivago's ass for the past few days. I've only met one /prog/rider in ##C so I don't know if anybody else has noticed this. It's quite painful to watch how badly he wants to be Zhivago's little lap-doggy though.
>>71
Was your first clue when he asked, "Who do I have to blow around here to get ops?"
Name:
Anonymous2010-01-14 4:10
These people make c.l.l look like a bunch of geniuses. Post-Naggum c.l.l, at that.
Name:
Anonymous2010-01-14 10:25
>>72
No, it was when he gave Zhivago's anus a big sloppy kiss every time he said something.
I mean I'm as big a Zhivago fan as anybody -- probably a bigger Zhivago fan than anybody, even aside from the fact that most people who encounter him probably think he is a big meanie or something. But god damn, this guy is just kissing ass like he wants a big promotion or something.
>>73
What is that, and how may I view it? What is this Naggum you speak of?
>>77
Who is anus did Zhivago have to eat to get op in that channel? What!
Name:
Anonymous2010-01-15 7:15
I can hardly believe the level of ass-kissing and illiteracy I just witnessed. Haven't any of my fellow /prog/riders been there in the last hour or so?
>>82
I can sometimes see /prog/riders in ##c,#haskell, #lisp and other freenode channels. There's the kind that just joins and memespams or does something equally stupid, which eventually gets him banned. There's the kind that does not appear to be a /prog/rider, except for subtle hints here and there that would only be obvious to a fellow /prog/rider, and of course there's my kind which doesn't slip up, but just silently laughs whenever he sees previous 2 kinds of /prog/riders in such channels.