| |
| |
| |
|
Page: 1 2
Comments:
<0> This is my first time in this room...anyone want to chat and tell me abt it
<1> doh
<2> ?
<1> i'm so bored and now depressed
<1> i dont know what to do
<3> what happened?
<1> i've been unemployed fora few months now-- it's starting to sink in
<3> well the only thing you can do is to keep searching for a job :>
<1> there's other problems too
<3> oh i see..
<1> but "searching" isn't very fufilling, not when i never get any calls back
<3> whats your major?
<1> i never graduated
<1> but i know computer programming and systems administration okay
<3> they require papers i guess...
<4> i apply to lots of jobs and dont get responses and i do have a degree
<1> doesn't make me feel any better
<1> my friend ( and co worker ) who was laid off at the same time
<1> he graduated and is in the same boat as me
<2> where are you?
<3> are you from the usa?
<1> mt.us
<1> but i am looking all over the NW usa
<2> what kind of work do you do?
<1> software engineering
<2> that's rather broad
<1> i've done a lot of crap. mostly web applications
<1> c, c++, java, python
<1> html, css, xml, xsl, javascript
<5> c-bot isdigit
<6> VonKanari, here you go: isdigit - #include <ctype.h> int isdigit (int c) Cl***ification of Characters (ISO) see - http://www.msunix.co.uk/manual/glibc-2.2.3/html_chapter/libc_4.html#SEC65
<5> hello?
<7> hello
<8> Is the exact meaning of volatile, implementation dependent?
<7> if I have an array of structures allocated dynamycally, structures containing pointers to functions and pointers to char (pointers to functions allocated by affectation) must I free these pointers first, before freeing the array of structures ?
<8> I guess you should
<8> if you are dynamically allocating memory for them
<7> allright :)
<7> http://www.cr***eux.com/books/ctutorial/volatile.html <-- Xing : for the keyword 'volatile'
<8> Thanks
<9> flupke: you're allocating memory for function pointers (your use of affectation in this sense confuses me)?
<10> thx
<10> is there any talk here ?
<10> c-bot hi
<6> nOuR_MaRiO, here you go: hello
<10> c-bot !trivia
<6> nOuR_MaRiO, the magic 8 ball says... concentrate and ask again.
<10> c-bot do u have games
<6> nOuR_MaRiO, the magic 8 ball says... reply hazy, try again.
<10> c-bot what games you have ?
<6> nOuR_MaRiO, *shrug*
<11> what was the va with the mixed_arguments for functions
<11> man page
<12> ?
<12> what do you mean ?
<11> man page of mixed argument stuff
<11> wos i can read
<12> mixed arguments ?
<12> you mean
<12> like printf ?
<12> variable number of argument ?
<11> foo(a , b , c , dynamica )
<11> right
<12> stdarg
<12> man stdarg
<11> yea k
<12> varargs its called
<12> not mixed arguments
<12> ;)
<13> is it ok to memcpy 0 bytes?
<2> you can't memcpy 0 bytes
<2> by definition
<13> well
<2> but memcpy won't die or anything
<13> k
<13> dbtid wacked? http://www.rafb.net/paste/results/81NTMV14.html
<14> you want to use memmove instead of memcpy there, and could you also post the definition of cbuf_t?
<13> why would they overlap?
<13> or is that about alignment?
<14> no, it's about overlap...
<2> memcpy doesn't handle cases where overlap between source and destination occur
<2> s/doesn't/isn't defined to/
<2> memmove is
<2> listen to sheep--
<13> i know that part, but i am wonding why they would overlap
<2> i dunno. listen to sheep--
<14> hehe
<2> i'm in the middle of something
<13> sheep why would they overlap?
<13> is this under the **** happens rule?
<14> yes, mostly
<2> winkey: language
<14> and language :P
<13> k
<14> well, it's better to be safe than sorry... memcpy(buf->buf + oldsize, buf->buf, write); i guess by your definitions they wouldn't, but if your sizes get screwed up, then this is just an extra bug on top of it
<14> can you post cbuf_t definition... i'm starting to doubt what you are trying to do here altogether
<13> about too
<13> http://www.rafb.net/paste/results/SHV6gi88.html
<14> like 41 seems useless to me... a = b + c; where c = a - b;
<13> well i have to convert it back from a size_t to a pointer
<14> what i mean to say is that you are not changing buf->read at all
<14> oh, unless it wasn't defined... but you should always intialize it
<14> when you originally allocate cbuf
<13> well if its empty i use NULL for read and write
<13> that way i can tell its empty and not full
<14> but if it's empty, size is 0, and this function reallocates size to size*2
<14> which will not accomplish much
<13> well
<13> empty as in theres a buffer alocated bnut nothing in it
<14> so... suppose there's 1 character in it, and you read it, adjust your read pointer, now read is the same as write, so you set them both to NULL?
<14> or do you not adjust stuff?
<13> i set them both to null
<13> want the whole mod?
<14> nono.. i get what you are doing
<14> line 46..
<14> if (read)
<14> if read is 0, it doesn't mean the buffer is empty, and it doesn't mean it's not...
<14> unless i'm missing something, this condition is not enough to check the amount of data in the buffer
<14> it could be that the buffer is full, but both read and write are at offset 0
<14> then lines 54-60 will not get executed
<13> ack and thats actualy pretty probable
<2> good catch sheep--
<2> baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah
<14> :P
<13> if (read && write) {
<13> fixed ;-)
<14> well..
<14> if read is 0 and write is 0, read && write is still false :)
<13> ack
<14> in fact, that's a weaker condition, because now only read OR write could be 0
<13> use a empty flag var then
<14> you are looking for something along the lines of if(buf->read != NULL)
<14> given your initial conditions, if the read pointer is set, the buffer is not empty
<13> ahh don't need to set them there already set
<13> i use a function to fetch a pointer and return a size of the data in the buffer (upto end)
<14> all you really need from lines 46-64 is lines 54-60 with the if condition modified to be if((buf->read != NULL) && (read >= write))
<14> because in all other cases, you don't need to modify buf->read or buf->write
<13> not sure i followed that
<14> lines 46 to 64 serve two purposes
<14> 1 (54-60) is to move the data if it needs to be moved
<14> and 2 to update the buf->read/buf->write pointers
<13> read and write posibly no longer point to the same area of memory
<14> but... your buf->read and buf->write pointers will only need changing in the case when buf->read != NULL and read >= write
<14> oh yeah
<14> oops
<14> nevermind then
<14> i'm used to read and write being integers :)
<13> i could do away with that else by moveing that upto where i set the read pointer
<14> well yeah, but that will pretty much yield the same thing anyway
Return to
#c
or
Go to some related
logs:
certwatch debian
#squid
eidleweisse
car suspenions
kollox bis suf
#c++
cannot run C++ compiled programs ubuntu
#linux
c++ classname_t
#MissKitten
|
|