20:57:15 hey, looking for whoever put my book "Learn C The Hard Way" into http://www.iso-9899.info/wiki/Books#Stuff_that_should_be_avoided so they can tell me why. 20:57:37 and i wanted to make a doubly linked list too, i can do the same thing with type doublylinkedlist and dll_* 20:57:54 zedas: is the wiki history useless for that? 20:58:15 nico103: probably yes, theres an "anonymous" account 20:58:28 nico103: ah good point let me look. 20:58:53 many (most) of the changes seem to be anonymous 20:58:57 just edit the page 21:00:26 zedas: someone was asking about that the other day, no-one really had a good answer as to why. 21:00:42 nico103: thanks, looks like it's a user named TypeOf'A' 21:00:43 hey zedas, I was learning from your book. Thanks. 21:00:53 that's the anon account 21:01:19 ha, so it's someone who wanted to be anonymous and do this huge edit? http://www.iso-9899.info/wiki?title=Books&diff=8815&oldid=1401 21:01:21 Title of zedas's link: Books - C 21:01:28 zedas: if you /topic then you'll see that's the account anyone can use. 21:01:46 iirc some people in here feel that lcthw teaches more "an implementation of C" than "C itself" 21:01:56 march 2k5? 21:02:26 it doesn't even teach that 21:02:30 IMO at least some rationale should be given for why a book might or might not be useful, and to whom 21:02:34 zedas: that's not one edit, that's lots of changes 21:02:36 it teaches what that particular guy does, when he's coding 21:02:39 zedas: It was me. Sorry for not providing reasoning. Feel free to move it back to where it was. I shall again move it where it belongs to, this time with proper explanation. 21:02:45 some books may be more for beginners, others for advanced programmers, ... 21:03:09 Vigud: well the book is still being written so if you have feedback on what's broken about it i'd like to hear it. 21:03:50 — nico103 pulls up a chair, makes popcorn 21:04:24 — Aman_ knocks nico103 off his chair and grabs the popcorn 21:04:57 kate`: so do you have specific things that are wrong? i can fix them if you do. 21:05:22 zedas: it's entire approach grates with me, as you already know 21:05:40 kate`: ok what grates with you about the approach? 21:05:40 zedas: I admire you for coming here, finding the culprit, and asking good questions 21:05:49 "culprit" 21:05:53 come on now 21:06:10 well, ok, whodunnit 21:06:16 better 21:06:27 zedas, i have neither the time nor inclination to address it. last time you made it perfectly clear that you're more interested in arguing confrontationally than actually listening 21:06:28 I myself am curious 21:06:32 nico103: it's actually not the first time ;) kind of like a déja vu 21:06:34 nico103: well i want my book to be good, so if people have specific technical or teaching flaws to point out i'd like to know. if they're just pissing on it to piss on it then i'd like to know why too. 21:06:34 I rarely read C books 21:06:40 nico103, he is simply here because his ego is under threat 21:07:03 ok, so I wasn't around previous times 21:07:16 meh 21:07:30 don't make me make popcorn for nothing 21:07:32 kate`: IIRC you said that you found a flaw in how I said NULL is 0, and then preceded to be wrong about that, but gave no other problems that were more substantial than one sentence on NULL. 21:07:46 zedas, we can make this much simpler: if it's still being written, then it very well belongs in the "stuff to be avoided" category 21:08:23 kate`: maybe; maybe lots of editions could be the next publishing model, as with software! 21:08:23 zedas: Does this URL refer to the book you're talking about? http://c.learncodethehardway.org/book/ 21:08:24 Title of Xgc's link: Learn C The Hard Way 21:08:42 Xgc: it is 21:08:54 kate`: well, thanks for being so rational about your assessment of the book. 21:09:11 Xgc: yep that's the book i'm working on. 21:09:21 zedas: what's the difference between char *c = "Zed"; and char c[] = "Zed";? 21:09:57 What is sizeof, and when does it "work"? 21:10:02 Vigud: is that from an exercise? let me find the chapter... 21:10:51 zedas: I haven't had time to review it. I just jumped to a spot and start reading. You have the following: // third way, pointers are just arrays Suggestion: Remove that. Never / ever suggest pointers are arrays. Be much more careful in how you compare pointers and arrays. 21:10:55 Vigud: actually let me write these down...then you can just pile them on and i'll explore. 21:11:23 Xgc: funnily enough, I'm reading another part which reads "You should *never* think of pointers as arrays" 21:11:33 so, it's broken, fundamentally. 21:11:40 well, he did say the hard way ! 21:11:57 Vigud: any more? I'm taking requests. and you're saying my description of these is wrong in the book? should I research the C FAQ? 21:12:13 zedas: Comment? 21:12:18 Xgc: which capter is that? 21:12:21 well, pointers can be thought of pointing to what might be an array in memory (as opposed to arrays as in [] decls) 21:12:21 chapter 21:12:29 AeroNotix: http://c.learncodethehardway.org/book/ex15.html 21:12:29 Title of Xgc's link: Exercise 15: Pointers Dreaded Pointers 21:12:35 Xgc: I believe I do that at first then change it, but I'll put it on the list. 21:12:41 zedas: you should get a copy of the standard. 21:12:43 this is the same as "hey guys, can you rewrite my book for me, while i keep calling it 'my book'?" 21:12:51 haha 21:13:18 Vigud: i've had several copies over the years, but thanks. are those the only two you can think of? 21:13:32 i think the idea is that if you have blatant contradictions in your book about something so basic, then it is not particularly irrational to reject the tome entirely even if one hasn't read the whole thing. 21:13:40 zedas: ex45 is POSIX C 21:14:16 Xgc: and that's in code right? in a comment, not in the prose? Ok, i'll check the comments too. 21:14:24 zedas: currently not. I'll need to re-read it, this time taking notes. 21:14:38 zedas: Yes. 21:14:39 Vigud: do you want to be a paid reviewer? 21:14:59 Is that a loaded question? 21:15:10 Xgc did you scroll down the same page and read the massive title that says: "Pointers Are Not Arrays 21:15:10 No matter what, you should never think that pointers and arrays are the same thing." 21:15:26 i think it's silly that you introduce duff's device and then say "don't use it" (exercise 23) 21:15:32 rob```: I saw that 21:15:38 it's like giving a kid matches and saying "don't set stuff on fire" 21:15:40 zedas, also and remove this page: http://c.learncodethehardway.org/book/krcritique.html 21:15:41 They are not, that'st true, but arrays are converted to pointers to the first element in some contexts. 21:15:41 Title of apocn's link: Deconstructing K&RC 21:15:43 Vigud: no i'm serious. do you want to make a little cash trashing my book and finding flaws. i will actually pay you. 21:15:53 either half of duff's device is ok though :) 21:16:18 you mean your and his book :) 21:16:26 sfo_: No. I just picked a likely spot in the book that might have problems (based on experience) and skimmed down. Didn't take long to find that. 21:16:37 apocn: why should it be removed? 21:16:44 zedas: Maybe something of interest: http://functional-orbitz.blogspot.se/2013/01/deconstructing-zeds-k-deconstruction.html 21:16:44 Title of Euthy's link: functional orbitz: Deconstructing Zed's K&R2 Deconstruction 21:17:11 kate`: no, it's my book. books are typically edited and technically reviewed by many people. 21:17:49 zedas: I'll do that for free, when I have time for that. 21:18:12 is there a good way to create a struct with a flex array member at the end without using malloc? 21:18:20 Euthy: thanks i'll take a look at that later. quick look though says the author didn't read too carefully. 21:19:03 Vigud: well i'm looking for people to do it now, and since you seem to be adamant about how bad the book is to the point of labeling it forever damaged, you are the best person to critique it. 21:19:13 j4cbo: not really, no 21:19:22 i have a struct like struct foo { int count; int items[]; }; - if i were mallocing one i'd malloc(sizeof (struct foo) + n * sizeof (int)) but i want to create one as a local variable 21:19:32 the best idea i've come up with is making a VLA of chars and then casting 21:19:33 Vigud: and i like compensating people who do good work. if not paying you then how about we work out a charity donation or something? 21:19:49 I need money 21:19:53 gief 21:20:11 zedas: in ex8 you don't use %zu for size_t 21:20:16 AeroNotix: ha, are you able to find flaws in my book? 21:20:20 sadly, union { struct foo f; char c[...] } my_foo; is invalid :( 21:20:28 zedas: i've pinged you with a couple 21:20:43 engla: ya know, i have to go back and review what to use, because i keep running into platforms where that doesn't work. 21:21:05 %zu is c99 21:21:06 AeroNotix: via email? alright email me again and we'll work out a deal. 21:21:17 rob```: he's using a C99 // comment right before it.. 21:21:41 but I know what you mean. But it's %ld too.. .not %u for unsigned 21:21:43 zedas, if perhaps you spent a little time familiarsing yourself with the various C standards, things like %zu might not be a surprise. and *then* you could write confidently about it 21:22:02 kate`: i'm focusing on C99, but thanks. 21:22:05 I'd suggest making the offer to Zhivago, but I'd much prefer just ask Zhivago to write a book on how to learn C the right way. 21:22:24 zedas: correct code will not say "WARNING". you can cast with printf and it will not crash/be memory unsafe 21:22:37 I'd prefer Zhivago just spent his time insulting people in here, thanks. Way more entertaining. 21:22:49 zedas: printf("%u\n", (unsigned)sizeof(obj)); is *always* safe, even if not correct.. 21:22:56 zedas: You might add a section or appendix that covers compromises made to account for incomplete or older implementations. Footnotes that refer to these cases could help clarify these choices. 21:23:02 engla: good point, thanks. 21:23:53 Xgc: that might be a good idea. i was going to cover incompatibilities in an appendix so maybe just roll those together. 21:23:59 For someone trying to learn, that could helpful. 21:24:01 so if you use %ld, at least cast to long on the right hand "side" of printf 21:24:03 could be 21:24:29 I was also thinking of linking to relevant C FAQ answers on each exercise, but there's so many so it might be too much. 21:25:49 zedas: Not a bad thought. But then you risk someone adjusting the C FAQ causing your readers problems. 21:25:57 How about this folks: If I put up a bug tracker or similar, and y'all trash the my book, would you be into me donating $1/original bug found to the EFF? 21:26:33 up to say, $1000. man I hope there's not 1000 bugs in the damn thing :-) 21:26:38 zedas: A mechanism for official feedback would be a good idea. 21:26:59 Xgc: yeah it was the comments but they got to be a pain in the ass to manage. 21:27:32 zedas: a bug tracker is an interesting thought, yes. 21:28:04 Vigud: ok, and i'm serious. i want brutal "Zed Don't Know Shit About C" feedback on it. 21:28:50 alright, let me go find a bug tracker i can throw up real quick that's not a pain in the ass to use.... 21:29:02 I never said that. I only found some places in the book where crucial details were left out. 21:29:52 Vigud: well, it kind of sounds like it from how you were talking, but I'm a big boy. i put my stuff online in unfinished form so it can be better. 21:30:11 kate`: I wasn't around for the previous iteration of this discussion, but from the looks of this one zedas is quite reasonable and rational; you're the one reacting badly (perhaps because you're biased by the previous discussion, but how can an observer observing this one know?) 21:30:17 but, i'm willing to put my money where my mouth is. i'll put up a bug tracker, tell you all where it's at, and you rack up the bugs, i pay the EFF 21:33:30 nico103, read about "gaslighting" 21:34:43 kate`: interesting; had never run into that term; thx 21:34:52 you're welcome 21:34:53 kate`, as respectable as you are, you're not too helpful. I realize you don't care about someone's book, but wouldn't it be better for the C newbies to improve shitty learning resources? 21:35:21 how would the newbies know the difference ? 21:35:29 why wouldn't you say that to PoppaVic? He just acts like a troll too 21:35:48 They can't and they won't if they read LCTHW as it is now, that's the point I'm trying to make. 21:36:03 Vigud: there are too many people writing substandard resources for me to deal with. they invariably have more energy than i. i have other things to do with what little energy i do have 21:36:32 At least stop repeating "you're wrong". 21:37:01 while you nerds talk about these shit, in the meantime, i met two girls and got a phone number feel the difference suckers! 21:37:12 Vigud, i don't believe i have repeated that 21:37:15 oh, i misparsed your statement, Vigud 21:37:17 Engin sisters don't count! 21:37:32 it was rather ambiguously constructed. 21:37:47 Engin: 50% is an F ;) 21:37:59 Aman_: no sisters buddy, two foreigners, you know what, i don't give a shit if yhey are relatives too anyway haha 21:38:40 lol 21:38:58 alright let's try lighthouse: http://lcthw.lighthouseapp.com/projects/104762-learn-c-the-hard-way/tickets/new i think it makes you create an account though. 21:38:59 Title of zedas's link: Add a new ticket - Learn C The Hard Way - lcthw 21:39:33 alright, i'm serious about this and I'll announce it later today. i'm going to pay $1 per original bug found in my book to the EFF. 21:39:51 ok that's neat 21:40:14 so try out the lighthouse app, if it sucks i'll find something else. if you say my book is "shitty", then I'm paying out of my own pocket for my sins, so you get to cost me money. 21:40:35 thrashing you in person was the biggest reward for me though ;-) 21:40:38 and, i'm putting my money where my mouth is: i want my book to be good, you all seem to have huge issues with it, so let's see you go for it. 21:41:07 It asks me how many minutes are in an hour, but doesn't specify on which planet. 21:41:23 or if it's in metric time 21:41:38 Vigud, i can put that more simply: i'm not the one choosing to author a book 21:41:56 engla: well glad to be tough enough for you to trash over IRC. :-) 21:42:05 Vigud, (this is not specific to zedas; i mean it to apply to many texts) 21:42:42 it's true, it's hard to trust C resources on the web. at least zedas is trying to fix it 21:43:02 by writing another one? 21:43:17 I'm sure you have reasons to teach people in this channel, one by one, instead of fixing popular but inaccurate learning resources. I get it. Nihil novi sub sole. Let's get over it. 21:43:17 !xkcd standards 21:43:28 rob``` :) 21:43:37 in my view, it's a basic fact of life: iteration counts. not so important to do it right first, more important that you stick to it and fix it 21:43:38 http://xkcd.com/927/ 21:43:39 Title of rob```'s link: xkcd: Standards 21:44:13 engla: exactly. i think this propensity of hackers to just shit on something that's in progress and declare it forever broken is bullshit. 21:44:25 Vigud, there will always be people who need help, regardless of what texts are out there. i find it rewarding to help individuals 21:44:36 zedas: Who declared it forever broken? 21:44:36 especially when i'm here saying, alright, if it's broken then go to town and enlighten me. i'll even pay up. 21:45:03 Euthy: it was placed on the FAQ for this channel as a book to avoid, and has been placed there several times without more than 1-3 flaws found in it. 21:45:12 zedas: are you talking about me? It was me who put your book on the "broken" list. 21:45:37 Vigud: no it was on there a few times before. it's alright though, i'm here to find out why you think it's so shitty. 21:47:24 well, come back when it's not WIP 21:48:15 zedas: Well, I guess it happens after we've had to deal with people confused by it. Not that I've been paying attention to it, but that sounds like a reasonable explanation. 21:48:30 Triskelios: you mentioned this yesterday (10:08:53 PM) Triskelios: Choicefresh: there are also malloc implementations that have built in reference counting/leak checking (e.g. libumem) 21:48:33 kate`: well i'd like to fix it now, which is why i'll donate money to the EFF for everyone in here that finds bugs in it. 21:48:52 is there somewhere i can find out how to use that? will it allow me to print Memory Leak/No Memory Leak the same way my counter does? 21:48:54 Euthy: please if you find people confused by it, just PM me and I'll come help them. 21:50:57 zedas, please do. but don't be surprised if it's not recommended reading while it's WIP 21:52:50 kate`: quick honest question: what general problem do you have with the approach? 21:53:41 zedas: Your "Deconstructing" section probably needs to be rewritten. It's built on a false premise, that your writting can (in some way) replace a book like "The C Programming Language". K&R is a much more complete treatment of the language. 21:54:34 If you need to pass a double* to a func. Is it more common to have the length be the first or second argument? 21:54:50 func(double*, size_t) or func(size_t, double*) ? 21:54:57 Xgc: thanks i'll take that into account. Did you find a bug in it though? If you do log a bug in the lighthouse so the EFF gets $1. 21:55:02 what's a double* ? 21:55:03 zedas: Your attempt is more a compilation of examples of language use. 21:55:45 zedas: It's just a very misleading section. It might drive someone to put your book down, if they understand the language at all. 21:56:07 hiptobecubic: why would it matter? 21:56:34 Xgc: alright, thanks. I'm not really writing it for people who can already code C but I'll take that into account. 21:56:56 zedas: It needs to be rewritten. 21:57:06 Xgc: I'm skimming through the book, I'm at the chapter where it says about stack and heap. I'd say there is no stack in C, but I know you disagree. Would you explain that for me and zedas? 21:57:19 Skapare, because consistency lowers the mental burden 21:57:23 i'm here to get paid by zed shaw 21:57:46 If we judge from BLAS, the size precedes the vector (provided as a float*) - if it makes any difference... 21:58:03 ok 21:58:21 fgets has the size second, but I'll go with BLAS :) 21:58:32 Does it make any difference? In all cases, i believe you can define your own API 21:59:03 sure, but if i'm working with numerical data there's no reason to differ from an api everyone already knows 21:59:25 zedas, i'm a little busy at the moment, but i'll explain later (perhaps by /msg) if i can 21:59:42 dcope: i'm donating to the EFF. 21:59:46 kate`: appreciated. 21:59:47 but the leading dimension follows in BLAS (often, not always) so you could argue it the other way too :P 21:59:52 There is only one case - to the best of my knowledge - where the order of the arguments does matter. Here is one example: void process2(int nRows, int nCols, float (*matrix)[nCols]); 22:00:04 zedas, i did attempt to do this beforehand, mind 22:00:08 zedas: You can't seriously think this book replaces in any way an effort like "The C Programming Language", even with any flaws it contained over the years. Honestly, it suggests you're either not serious about C or don't know C well enough to write about it. That's my take, after 35 years with C (seeing the good and the bad, professionally). 22:00:31 kate`: if i remember correctly, you said the book would "permanently damage any student reading it" then went off about a minor flaw in describing NULL. 22:00:55 zedas, essentially i think you're mixing several topics into one text. one of them is what "the practice of programing" covers 22:00:57 kate`: i'm more interested in what your problem is with the book in a general way, but a way i can fix or at least understand. 22:00:58 zedas: That's why I'm suggesting you adjust it, so that you don't seem as though you don't know the difference. 22:01:01 paranoid1324, sure, but it's nice not to have to think "which one was first again?" every time you switch between my functions and BLAS (which will be common) 22:01:36 zedas: generally, what I don't like about your book is the notion that C code gets compiler and runs natively. But that's one implementation. It could be interpreted much like JS is interpreted by Internet Explorer 6.0. 22:01:39 zedas, i don't think you can "fix" this, because you have written out the way you work. i think that's probably fundamentally attached to your personality 22:01:42 kate`: ok, so your problem is i'm teaching C and how to program in C? interesting. 22:01:44 hiptobecubic: Oh, then fine! 22:01:46 paranoid1324, the compiler will tell you about type errors, but they aren't logic errors they are just annoyances. No one likes swapping argument orderings around 22:01:59 zedas: I only glanced at your deconstruction but maybe you should reconsider your tone and angle? We might end up with a lot of people dissing K&R only because they take your word for it, instead of having a look at it and forming their own opinion. People are like that. 22:02:03 zedas, amongst other things. i can't hold a conversation right now, sorry 22:02:22 kate`: and you believe that this will fundamentally damage students to learn? or just my way of teaching it? 22:02:31 The "stack and heap" chapter reinforces the feeling. 22:02:41 kate`: alright, feel free to write me a long email if you want at help@learncodethehardway.org and I'll read it. 22:03:05 zedas: I've never looked at your book; I would reject kate`'s argument out of hand; I would instead say that there's a place for decent reference-type books, general practice of programming books, and "learn C and programming" type books 22:03:14 Vigud: so you believe this too? that i don't teach the language but just the language that people use and that's damaging? 22:03:19 not everyone will need more than to get past some immediate problem 22:03:39 zedas, no. the damage referred to other things. sorry, i'm not going to email you; i'd rather spend my time dancing 22:04:02 kate`: alright, well if you feel inclined to tell me please do. 22:04:09 I don't mind having lots of neophyte, naive programmers around, just as long as they get taught shit like SQL/shell/... injection vulns 22:04:20 zedas: yes. 22:04:23 kate`: that I can agree with you on 22:04:31 I too would rather spend more time dancing 22:04:42 Vigud: one thing i'm going to ask from you: Instead of trying to trap me with tricky questions to get me to demonstrate I don't know what I'm talking about, just tell me what you think is wrong and possibly where to go learn more. Thanks. 22:04:47 nico103 :) 22:05:45 — Xgc goes back to work. 22:05:49 Choicefresh: libumem is very powerful and reasonably well documented. if you're using the portable version you may have to figure out how to get the debugger macros to work 22:05:55 zedas: I didn't mean to trap you. I asked the two questions I asked because I believe they should be answered in the book. 22:06:27 nico103: you can dance if you want to, we can leave your friends behind 22:06:41 Vigud: well those and just now a leading question on the stack. Instead maybe go, "I think your description of the stack is wrong in ExYY. Go read J to understand it better." 22:07:13 But I already told you to read the standard. 22:07:13 rob```: hey, how'd you know my friends mostly don't dance? 22:07:56 Vigud: "read the standard" isn't very specific, but if your answer is that for everything then fine. At least just say what's wrong and where so I can fix it. 22:08:10 nico103: cause your friends don't dance and if they don't dance, well, they're no friends of mine! 22:08:12 Vigud: and remember, everything you find I will pay to the EFF. 22:08:57 rob```: har 22:09:29 ok folks, i'm going to do some work. please PM me if can't use the lighthouse bug tracking to tell me bugs you find. 22:09:55 i'll pick a different one if it doesn't work. also if you just want to email me the bugs then email help@learncodethehardway.org and I'll post it for you. 22:10:01 zedas: While I generally take a different approach to "stack" discussions, I take a different approach for an author. You really should have a better response to Vigud's comment. Just try to find the sections that deal with "stack" in the specification and get back to us. 22:10:17 nico103: https://www.youtube.com/watch?v=lzXcFfU81sg ;) 22:10:18 Title of rob```'s link: Scrubs Turk - Safety Dance - YouTube 22:10:51 :) 22:11:02 Xgc: I'm trying to remain objective and open about things people found. Getting into a "I'm Smarter Than You" pissing contest about obscure C trivia won't help with that. 22:11:02 zedas: I think they're meaning that it's not a stack vs heap kind of memory thing, it's a "memory lifetime" thing. 22:11:24 The fact that there is no "the stack" in C is not just trivia. 22:11:42 zedas: That's not what people are doing ... 22:11:43 Xgc: so in order to do that, I'm just taking any feedback you have, and not commenting good or bad on it. 22:12:07 vigud: uh, you're right, and there are C->JS compilers 22:12:18 and it's true that there's no "stack" as such 22:12:26 that is, there doesn't have to be 22:12:38 How can I make a ptr+x non-permanent? 22:12:45 but in practice in all the major ABIs I know of there is 22:12:45 Euthy: yes, it is. but irrelevant to my goals here. i got the bug tracker up and an email address and I'm shelling out money to the EFF. Not sure what else I have to do in order to get solid feedback but I'm trying damn hard. 22:12:50 tziOm: what does that mean? 22:13:05 and so on 22:13:06 zedas: That's not my intent at all. But when talking about "the stack" you should have a much more immediate / clear response. I'm not going to put words into your mouth. I think you'll see when you try to find that detail in the specification. 22:13:21 why would any book teaching C to beginners mention C interpreters? 22:13:22 I think it'd be fine for zedas to point this out somewhere and yet still speak of the stack 22:13:42 is zedas's book about the C standard? 22:13:48 nico103: Correct. 22:13:50 typically the way I've seen this done is with smaller type in inset boxes that note such things 22:14:05 so, really, I think some level of abstraction and hand wavyness is to be expected from intro books 22:14:11 and I can't blame the author for it 22:14:13 wmoxam: because it's the best way to think about the language C - that you're working with an interpreter, which, for example, uses linked list instead of the stack. 22:14:22 I mean, we can all be pedants, but not the beginners 22:14:28 Triskelios: My professor said specifically, "using a global variable is not acceptable; also, updating that global variable each time malloc/calloc/free are used makes the code depended on that global variable. Here is a challenge for you: write a memory leak checker that does not depend on a global variable. Think about it. I can give you some hints." 22:14:30 Xgc: So if I reword your and Vigud's question to be actionable it's: Your understanding of the heap vs. stack in http://c.learncodethehardway.org/book/ex17.html is flawed and seems to confuse the memory life times of data? 22:14:30 Title of zedas's link: Exercise 17: Heap And Stack Memory Allocation 22:14:43 and being utterly pedantic to a beginner is really the same thing as making your audience go away 22:15:07 zedas: No. 22:15:11 zedas I'm sorry I missed whole thing, are you writing a book about C ? :) 22:15:18 Choicefresh: you need to think about it, then. but leak checking should be done completely transparent to the program 22:15:22 nico103: yes so the hard part is delivery 22:15:22 zedas: no 22:15:48 zedas: their complaint is that C has no such thing as a stack in the abstract; only implementations of C (and their corresponding ABIs!) have stacks 22:16:06 zedas: If that's the attitude you have towards other human beings, don't whine when they don't feel like explaining why they don't like your book. 22:16:12 zedas: therefore when you speak of the stack you clearly show that you have no idea what you're talking about 22:16:16 but, really, come on 22:16:18 zedas: the "heap" and the "stack" are just implementation details! they happen to relate to behaviours of C for storage duration! 22:16:23 give the beginner a bloody break 22:16:23 nico103: Thank you, that's better. 22:16:35 mind you, there is a problem with speaking of stacks 22:16:41 Triskelios: name one implementation who does not have stack 22:16:59 namely that people get tempted, them to reify stack addresses 22:17:09 nico103: So, the description I'm giving is of how a computer works and not specifically how C works. I can clarify that. 22:17:29 zedas: take input and move on -- don't listen to everyone :) 22:17:32 Engin: the above C -> LLVM -> JS compiler 22:17:33 really, one of the big problems with C is the lack of a type that represents closures (whether of indefinite lifetime or not) 22:17:42 zedas: not the computer... Triskelios already told you: implementation details. 22:17:46 zedas: not even of how the computer works 22:17:48 Triskelios: please speak english 22:17:49 lists of #include go inside the header file, isn't it? 22:17:52 how the ABI expects programs to work 22:18:17 you can easily write stack-less programs on x86, for example 22:18:28 Triskelios: my question is simple "name any C implementation without stacks" -- I'm not even asking name one MAJOR C implementation who does not have a stack. 22:18:30 there are stack-less Schemes that compile into native code that do that 22:18:35 Vigud nico103 Uh, so ever more pedantic? Not how the "computer" works, but how the ABI, on an OS, in a computer with CPU, using C, works? 22:18:40 Triskelios: Transparent to the program, as in using third-party software? I think she wants to be able to have the program print "Memory Leak" or "No Memory Leak". 22:18:47 Got it, i'll be sure to clarify that. 22:18:51 long story short, stack is highly relevant, so suck it up 22:19:01 Engin: I just did. if you compile C to LLVM bytecode, and compile that to JavaScript, you have no stack 22:19:02 zedas: no, I'm explicating Vigud's position as I understood it; I'm not advocating ever more pednatism 22:19:22 Triskelios: ok, I rest my case. 22:19:42 indeed, I'm saying that if you must explain these details then do it in small type in an inset box labeled for advanced C readers, or whatever 22:19:48 zedas: C -> LLVM -> JS does not have a stack -- are you stupid ? why are you describing stacks ? which are totally irrelevant. 22:20:05 but also 22:20:13 Engin: there are others and they are used. Moreover, there can be more in future. 22:20:17 Engin: I don't think you're helping. I'm actually trying to get feedback on this. Thanks. 22:20:17 it really probably is better to speak of activation frames than of stacks 22:20:21 Engin: that's totally the common case, and a beginner totally needs to know that :p 22:20:32 (even though there's frame-pointer-less implementations too) 22:20:36 Vigud: name one 22:20:36 there's nothing wrong with describing the heap and stack, as that knowledge is useful 22:20:49 but the omission of the C concepts which they help implement is a glaring one 22:20:54 so stop busting balls of this fellow over something pedantic 22:20:58 Vigud: cool i'll look at how to explain this more from the machine/os perspective and I think then get into how C doesn't care about this. 22:21:35 Choicefresh: are you thinking of a malloc/free replacement? 22:22:14 zedas: As an author, you know that being pedantic (painfully correct) is your goal. Anywhere you stray from that should be clearly documented. 22:22:39 engla: Um, or some sort of library recommendation maybe. I'm not exactly sure 22:24:14 zedas: The last thing you want to do is to mislead a reader. 22:24:39 zedas: I'll try to file tickets over time. But I feel something else is important: you need to convince yourself that the C language is more abstract than your book shows. If you're teaching a language, you need to be pedantic and not assume that GCC + Glibc + Linux is what everybody will be using in 10 years. We may have CPUs interpreting C by then, who 22:24:39 knows. 22:24:42 BTW, many eons ago I found that understanding the "C stack" (I know, I know) and activation frames helped me understand the concepts of lambda the ultimate goto, stacklessness, continuations and continuation passing style, ... 22:24:45 I take that back. You never want to do that, even as the last thing. :) 22:24:51 Xgc: I disagree with this. You don't have to tell the reader all of the details right away on everything. It's better to build them up in a logical sequence. But, that's just a style point not relevant to this discussion. 22:25:00 it depends on your goal. sometimes a convenient simplification is necessary, but then people need to know that they are reading a book of convenient simplifications. 22:25:08 zedas: No. But you never want to mislead. 22:25:21 Xgc: abstractions are misleading 22:25:23 zedas: also, I don't think it concisely explains exactly what the C preprocessor's role is and how preprocessor tokens and macros work with text substitution as a separate grammar 22:25:27 eventually they leak 22:25:32 Vigud: Well I'm teaching practical C programming on real computers not imaginary ones that have no stack, but I get your point. 22:25:36 and then you need to learn what lies below 22:25:37 maybe I missed a section, though 22:25:53 you have to make a comromise -- and tell them there are than meets the eye and details shall be revealed later 22:26:03 Triskelios: ah good call, actually I abuse the hell out of the CPP and can't exactly explain how I do it. I should research that. 22:26:03 just tell them with good analogies 22:26:04 nico103: Not at all. 22:26:20 that's what I believe and if you can't tell it like you can to a 5-year old -- you don't know the subject well enough 22:26:23 what's the general approach to finding if a string contains all blank space? 22:26:32 you MUST be able to tell it in a very simple manner -- otherwise you educate yourself first 22:26:32 zedas: You're missing the point, obviously. 22:26:39 er white space. i have this defined to use, btw: #define WHITESPACE " \t\n\r\f\v" 22:26:44 shibby: man strspn 22:26:48 zedas: I'm for your approach (for an *intro* text) with enough breadcrumbs left behind for the more capable students 22:26:54 hm yea i was thinking that one 22:27:26 zedas: the point is that the rules of C are the same whether there is a stack or not. you should explain how those rules work 22:27:50 the man page for strspn is so fucking cryptic and shitty 22:27:57 i wish i knew the author of it so i could shit on their front porch 22:28:07 here, here's your manpage. asshole. 22:28:21 Triskelios: wait, you said there is no stack. How can you have rules for a stack that doesn't exist? 22:28:50 shibby: that depends on the system 22:29:00 Triskelios: I think the problem is "stack" needs to be a different word. Function parameters or something. I'll research that more. 22:29:15 zedas: I think there is a gap in your understanding of C. this is why we said there is no "stack" in C 22:29:34 zedas: Triskelios said nothing about rules for stacks 22:29:36 zedas: there are variables declared with different storage types and durations 22:30:16 certain forms of automatic duration happen to be implemented as a stack 22:30:18 zedas: I do think Triskelios has a point; specifically you need to explain what is the expected extent of atutomatics 22:30:24 which is why it's called an implementation detail 22:30:46 if you do that first *then* you can speak of stacks as a natural (and de facto) implementation of that 22:30:59 The fact that there is no "the stack" was just an example of crucial detail. A better one, perhaps, would be that there are no global variables in C. It becomes clear why, when you ask yourself why your global doesn't work. 22:31:06 Triskelios: that could very well be true, and to fill that gap I'm going to take all the bugs found and then learn every bit of trivia I can about them. 22:31:08 it's like the difference between the concept of a hash table and a specific hash function 22:31:23 zedas: The concept, if you read the specification, is there. But there's no formal requirement of a physical stack. This is the type of treatment I'd expect from an author who knows the language. Remember, K&R1 explicitly uses the term "stack". So we're not saying you should never use the term. Just be clear about language requirements .vs. typical implementations. It wouldn't take much to show you have a full grasp of this and to 22:31:25 nico103: right, that's the feedback I'm getting too. 22:31:34 that is, C says something about the expected extent of automatic variables and *addresses* of them, and it turns out that stacks make for a very natural (but hardly *only*) implementation of those rules 22:32:03 Triskelios: also yes, different storage types on different implementations, but if using the "stack" is verboten then I'll have to research the better phrasing. 22:32:23 Xgc: Cut off at "a full grasp of this and to". 22:32:52 It wouldn't take much to show you have a full grasp of this and to help new readers. 22:33:21 Xgc: And your saying that understanding the abstract rules but *not* how they are actually implemented is better? Or you advocate both? 22:33:38 zedas: Show a full grasp of both. 22:33:43 of course, in practice it's very difficult to GC C (heh) without leaving a lot of crumbs in the internals of the activation frames, so that stackless C is unlikely in practice when compiling into native code (mostly because none of the relevant ABIs allow for such breadcrumbs) 22:33:51 you definitely need to understand the implementation to some degree to do any useful debugging 22:34:19 Triskelios: i believe I was focusing entirely on implementation and how to use it with valgrind, so I'll research it more and agument with both. 22:34:26 zedas: I'm OK with you speaking of the stack; however I think you need to start by explaining what the automatic allocation storage class is 22:34:35 that's the pedantic in me 22:34:59 you can, and really, should do that, and it needn't come across as pedantic to your newbie readers 22:35:01 nico103: but, don't call it a "stack" :-) 22:35:05 zedas: Especially in a book (like yours) which is designed to show practical usage. It's important (imo) to note how this steps outside the strict language text. So the first time you talk about a stack, explain how this fits into a language which does not define that term. 22:35:09 not at first 22:35:21 first "an automatic variable has these properties" 22:35:25 then 22:35:36 zedas: It's fine to use the term. Just clarify. 22:35:53 "typically this is implemented as a stack of function call activation frames" 22:35:57 probably makes sense to explain scoping and stuff in the same section? 22:35:59 now wordsmith that 22:36:01 and there you go 22:36:12 Triskelios: yes, scope and extent 22:36:12 zedas: New readers will not know when your writing steps slightly outside the requirements (formal terms) of the specification. 22:36:21