Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / One for the experts... (I/O Data Retrieval Weirdness)

Author
Message
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 7th Jul 2008 21:33 Edited at: 7th Jul 2008 21:34
Ok boys and gals, I is running this code:



Which is filling Memblock with the second set of data in the screen shot attached to this post.

All the correct data is there right enough except the bit on the end (where the <<<< bit is) which isn’t in the datafile I created and saved. Now it isn’t a massive problem because my data retrieval code can ignore it easily (I count data slots by the ¬'s you see) but I can't work out where it's coming from or how to remove it because I would prefer if it didn't exist at all.

I've tried the c++ file size reading method which doesn’t return a different result to the DGDK one (hence why I used the DGDK function rather than the c++ one; cus it's shorter) so I don't know what’s generating that bit of rubbish.

Anyone got any ideas?

We are here and it is now.

Attachments

Login to view attachments
Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 8th Jul 2008 00:51
lets see your file saving code

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 8th Jul 2008 12:16
As you can see in the screenshot I posted, the data on the right shows just one line of data. Currently I cannot separate the different bits of data from the single line of data which I can retrieve. Once I’ve worked it out and perfected it, I’ll post my entire method.

In the mean time you could have a look at the following webpage which I used to learn how to use the C++ I/O functions:

http://www.cplusplus.com/doc/tutorial/files.html



We are here and it is now.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 8th Jul 2008 12:40
How are you outputting the file? It almost looks like you're just filling your buffer with the file contents and outputting it as if it were a string, but it isn't a complete string as it isn't zeroed, to fix this allocate a buffer that's 1 char larger and write a 0 to the end, i.e. 'memblock[size] = 0;' that should fix it unless I misunderstand your issue.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 8th Jul 2008 16:59 Edited at: 8th Jul 2008 17:06
The memblock is created thus:



And filled thus:



Which should, in theory, fill the memblock exclusively with the content from the file...but it isn't, that's the issue.

If I did what you’re saying just after the:



I don't see what difference it would make considering the following line just copies everything present within the file into the memblock.

As a side note, I have now managed to form a method of data extraction using the string functions string.find() and string.copy().

Additionally the information I am removing from the memblock doesn’t seem to include the garbage I showed in the screen shot although I want to run a few more tests first before that's definite.

As I said, it probably doesn’t matter but I would rather it wasn't there for completeness.

We are here and it is now.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 8th Jul 2008 17:22
Quote: "I don't see what difference it would make considering the following line just copies everything present within the file into the memblock."

... And then the string outputting function reads past the end of the buffer because it is not zero-terminated, I assume. Here's a tip: don't treat binary data as a string.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 8th Jul 2008 18:06
Sorry I'm not following you.

There are no strings in my code until the data extraction code and that is only because I need to run string.find and .copy and even then, it never touches the saved data.

Memblock is a char* (as you can see in the second code snip where I used 'new char') which is set to the size of the file, i.e. it's size corresponds with the characters within the data file, character for character.

The reason why none of this matters and why it works is because the rubbish characters only appears on the end of the memblock and my file reading counts per '¬' character within the memblock char*, after it has been converted to a string. I know how much data is inside the data file itself, vis 15 different data elements, therefore I can run a data extraction loop 15 times to place the data into 14 slots on a char multidimensional array. From there it's just a matter of copying the data out of all 15 slots to the right variables to load the data into the program.

There is no way the data file reading or writing can possibly cause a memory leak because each data element is handled individually and there is not error in data conversion from the data file to the memblock and back again, only a bit of rubbish on the end of the memblock. Besides, I check both the saved data file in notepad and use dbText() to see what values the variables actually have in real time program operation and that all seems grand. If I wasn’t using dbText() then I wouldn’t actually have noticed anything odd on the end of the memblock at all because everything else works fine.

If you don't understand that you will when I post my entire code later on for file saving and loading and you can check it yourself.

We are here and it is now.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 8th Jul 2008 18:09
Quote: "If you don't understand that you will when I post my entire code later on for file saving and loading and you can check it yourself."

This is a good idea.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 8th Jul 2008 18:40
Thought it might be.

We are here and it is now.
Sephnroth
21
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 8th Jul 2008 21:59
Quote: "As you can see in the screenshot I posted, the data on the right shows just one line of data. Currently I cannot separate the different bits of data from the single line of data which I can retrieve. Once I’ve worked it out and perfected it, I’ll post my entire method.

In the mean time you could have a look at the following webpage which I used to learn how to use the C++ I/O functions:

http://www.cplusplus.com/doc/tutorial/files.html"


thanks - but I understood the code, I just wanted to see how the data was put into the file as I was concerned the rogue data was being put inside it, not generated by mistake when the data was loaded.

Glad its sorted

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 9th Jul 2008 00:09 Edited at: 9th Jul 2008 00:12
See below:

Ole fumble fingers....

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 9th Jul 2008 00:11


Not really critical to your problem at hand but, if you're going to assign a span of memory to the memblock pointer, you don't need to initialize it to "". The declaration creates an area of memory of one character with a value of zero and points memblock at it. By changing the value of memblock you no longer have a reference to that one byte. Not that you actually need it but it's one of the little things that bothers me a bit.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 18:42
Sephnroth - Ah. Na, it's just appearing out of nowhere when the dbText() command is called. Couldn't tell you where it's actually coming from but as I say, my data extraction method doesn’t seem effected by it as I’m treating each data element individually and those remain intact.

Thanks.

Lilith - *Shrug* It makes no difference either way; the "" is less than a character (I think) and even if it's just a single character it's no different to just assigning it new char, is it?

Ludo - Right then, I got the data extraction code working and the bit on the end makes no difference to what comes out in the end so I’ll post what I have and we will see what you lot make of it.

It's a bit messy but it's just a prototype program before I used the actual method, far more refined, within my game's framework.

Check the new thread.

Cheers.

/Ludo

We are here and it is now.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 18:48 Edited at: 9th Jul 2008 18:48
Quote: "the "" is less than a character (I think) and even if it's just a single character it's no different to just assigning it new char, is it?"

It is a single character. If you want to assign nothing to it then use NULL.

dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Jul 2008 19:20 Edited at: 9th Jul 2008 19:21


Yes, this code will read the file contents and as you say it works fine, but as I said earlier, this isn't a string, it's binary data as Benjamin pointed out. You then say "it's just appearing out of nowhere when the dbText() command is called", which leads me to assume you're directly passing 'memblock' (which isn't yet a valid string) to the dbText function, this is what I was trying to tell you earlier. dbText() has no way to magically know how long the string is, you must tell it how long it is by zero terminating it, aka adding a byte of 0 wherever the string ends, the above code doesn't do this. Thus dbText reads your binary data and reads memory past this until it hits a zero somewhere. As I said, to fix this you must dynamically allocate a string that's 1 byte larger than you currently are and make the last char 0, this will make your 'memblock' a valid string.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 19:59 Edited at: 9th Jul 2008 20:02
Ah! Your quite right, I was passing memblock into the dbText() function without converting it into a string but converting it into a string before running data extraction.

The reason I got confused about what your were talking about, asides from not realizing that I was passing memblock into dbText(), was that my data extraction code was not returning any errors, but it wouldn't because I am only extracting 15 different data elements, individually, so it wouldn't ever check for any data past how much data can only be within the data file converted into the memblock char* and then the data extraction string.

So am I right in thinking there is no point in my zero terminating memblock because I turn it into a string before performing data extraction then because I don't do anything with memblock asides from using it as a buffer prior to string conversion?



We are here and it is now.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Jul 2008 20:14
You still have to do it, when I say string I don't mean std::string; though you can use this if it makes things easier for you. When filling the std::string, using your char* string, you need to pass a zero terminated string otherwise you'll get the exact same problem; std::string too doesn't know where you want the string to end.

So either way, you must zero terminate it first.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 20:24
But why though? Memblock, and by association S, still contains the line of data from the saved file, in perfect condition, and I only check the first 15 data elements during data extraction and nothing else. The small line of rubbish on the end of memblock/S is copied and then ignored right up until both memblock and S are removed when the program shuts down.

I mean the only thing saved here might be about 30 bytes of data...alright if I did that with all my functions then there would be a little wasted memory I suppose but it seems a bit pointless when you come to think about wasting maybe a meg of memory.

I'll see to it at some point I suppose.

We are here and it is now.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 9th Jul 2008 20:40
Quote: "Lilith - *Shrug* It makes no difference either way; the "" is less than a character (I think) and even if it's just a single character it's no different to just assigning it new char, is it?"


I wasn't trying to make something big of it, just point out a bit of unnecessary code and some, yes, minor waste. As a matter of practice, however, it's something to at least be aware of. As Benjamin said, I'd assign it NULL or not even declare it until memblock was to be used to assign it to the newly alloted space.

However, having taken a closer look at the code, I notice, at least within the code you've shown, there's no request to delete the space allocated for memblock.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Jul 2008 21:12
Quote: "But why though? Memblock, and by association S, still contains the line of data from the saved file"


Yes, 'memblock' contains the file data exactly, however! File data is not a c-style string, it does not end with a 0 byte, thus you cannot use it in any string functions such as assigning it to an std::string or calling dbText. To do either of these you MUST zero it, otherwise as I said many times above these functions have no way of knowing how long the string data you wish to send is, all you're sending is a single address remember, a pointer to a char array, this array length can be anything and the function doesn't know so it just keeps iterating at and past that passed address until it hits a 0 then it knows the length. Hopefully I won't have to explain this again .

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 22:14
Lilith - K I didn't mean to sound like I was annoyed if I did cus I wasn't but firstly memblock is a Char* which I named memblock as its momentary container of information and we don't delete char*'s, no? Secondly the thing is declared as a global variable currently and it's only actual usage in the entire program is:



and...



So to be honest I could create it via 'char* memblock' but I always set varibles to something, even if it's just "".

dark coder - You might you know cus I'm still not following what your getting at. Here's the code:


K that is, in one block, creation of the variables, data extraction from the file and converting of the char* variable 'memblock' into the S string.

Now when I run my data extraction code I get exactly what I'm looking for, i.e. what is inside of and what I put into the data file.

Quote: "Yes, 'memblock' contains the file data exactly, however! File data is not a c-style string, it does not end with a 0 byte, thus you cannot use it in any string functions such as assigning it to an std::string or calling dbText. To do either of these you MUST zero it, otherwise as I said many times above these functions have no way of knowing how long the string data you wish to send is, all you're sending is a single address remember, a pointer to a char array, this array length can be anything and the function doesn't know so it just keeps iterating at and past that passed address until it hits a 0 then it knows the length. Hopefully I won't have to explain this again ."


But what you’re saying makes no sense.

I put the contents of the data file into the memblock char* variable and then extract my data from it by putting the contents of the char* variable into a string. I get no errors and the extraction code proves you a liar by extracting the exact data from the string that I know is the same as inside of the saved file.

I convert using the code above both the data file into char* and the char* into a string.

I mean, are you saying that I need to add a zero onto data file so it knows when to end before turning it into a char* and then a string or what becuase I have no idea why that would do anything but make the char* and the string have a zero on the end of it prior to the rubbish data...

We are here and it is now.
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 22:26
Quote: "I put the contents of the data file into the memblock char* variable and then extract my data from it by putting the contents of the char* variable into a string. I get no errors and the extraction code proves you a liar by extracting the exact data from the string that I know is the same as inside of the saved file."


Why are you putting it into a string?

If you want to debug the contents of the data, hex edit it, or view it an debugger. By presenting it as string (regardless of whether it goes into a string type or not) if the data is binary, it will be unreadable as ASCII (and in a lot of cases, most of it will be blank space because the data cannot be interpreted as text etc.)


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 22:29 Edited at: 9th Jul 2008 22:31
Dude, read the entire thread before posting, my method works perfectly the way I am doing it, we are discussing ways of removing some rubbish data from the end of a string or a char* and I am not looking to debug anything.

Quote: "If you want to debug the contents of the data, hex edit it, or view it an debugger. By presenting it as string (regardless of whether it goes into a string type or not) if the data is binary, it will be unreadable as ASCII (and in a lot of cases, most of it will be blank space because the data cannot be interpreted as text etc.)"


...am I using a different kind of c++ to everyone else here becuase I seem to be doing what people say cannot be done...

We are here and it is now.
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 22:31 Edited at: 9th Jul 2008 22:31
Quote: "Dude, read the entire thread before posting, my method works perfectly the way I am doing it, we are discussing ways of removing some rubbish data from the end of a string or a char* and I am not looking to debug anything"


Why are you putting binary data in a string then? Debugging its content was the only sane reason I could think of for putting in a string - so you realise you won't be able to read/understand its content?


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Jul 2008 22:31
OK... Let me explain this again. There is NO rubbish data in your 'memblock' char* array, the char* array is filled with exactly what you want, the file data! It is 100% retained, BUT! This char* array is binary data, it is NOT a valid c-style string as you have noticed when trying to use it in c-style string functions such as dbText and std::string's char* assignment operator. The issue is that, these c-style string command functions requires just that.. c-style strings. Which means you have a series of chars that's terminated with a char of 0, think of it as a full stop. If your char* array has no full stop at the end of the allocated array size, then it is not a valid c-style string, these string functions will continue reading past the total length of 'memblock' and begin reading the memory that's after this, this memory can look like rubbish, or garbled characters and you could even get a runtime error if you attempt to access memory that is outside of the application's virtual memory.

Because of this, you need to zero-terminate your char* array, this way such issues do not arise, all the c-style string functions know when to stop reading and you no longer see garbled characters when outputting this binary data as a string. Do you understand now?

Of course, as you're only using this for file parsing you don't even need to make 'memblock' a string, I assume you were only doing that for debug purposes? Or so that you could use some type of string explosion function?

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 22:33
Quote: "string s = memblock ; // Convert the memblock from char* to a string so the functions below will work"

Have you zero-terminated the memblock buffer first?

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 22:40
Quote: "Why are you putting binary data in a string then? You realize you won't be able to read/understand its content?"


You do realize you don't know what you’re talking about because the data on the right of the image I posted at the top of this page is the contents of the memblock char* when posted to the screen via dbText() so don't tell me I can't read the contents of the dam thing.

dark coder - K...what?

Lol, na seriously, I use:

Scribe->read ( memblock, size ) ;

To put memblock with the contents of data file.

Then put the contents of the memblock into a string, thus:

string s = memblock ;

Which allows me to run any string functions I like on S which I need for data extraction.

...What your saying is .find and .copy could run into memory which don't exist and end up crashing the program, yes?

We are here and it is now.
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 22:42 Edited at: 9th Jul 2008 22:45
Benjamin - No because memblock isn’t a 'Memblock', it’s a char pointer.

Quote: "Why are you putting binary data in a string then? Debugging its content was the only sane reason I could think of for putting in a string - so you realise you won't be able to read/understand its content?"


I've already answered this but 'Sane' reason, how ostentatious.

We are here and it is now.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 22:44
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 22:47 Edited at: 9th Jul 2008 22:49
Quote: "You do realize you don't know what you’re talking about because the data on the right of the image I posted at the top of this page is the contents of the memblock char* when posted to the screen via dbText() so don't tell me I can't read the contents of the dam thing"


I think the root of this problem, is that you only want to store ASCII data. You're opening the file with ios::binary, so it expects to read only binary data, not strings.

If you were actually reading binary, you wouldn't be able to see it as ASCII. Because you're reading as ASCII, but opening in binary mode, you can read the ASCII text, but you're also getting the binary trash on the end.

EDIT: Sorry, it's not ios::text. Just remove ios::binary, and it will default to text


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Jul 2008 22:47


Quote: "Then put the contents of the memblock into a string, thus:

string s = memblock ;"


'memblock' is not a string, std::string's assignment operator for char* expects a c-style string, a binary char array is not this. I've said this many times before, re-read it.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 22:48
Sorry, my bad, I thought you were referring to something else.

char* memblock = "" ;

That is how I declare it and it doesn’t seem to get annoyed at any point. I've been told to declare it as null but quite frankly I could just do:

char* memblock ;

And it wouldn't make any difference to the way the program functions.

We are here and it is now.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 22:49
I'm talking about zero-terminating it after the data has been read into the buffer. Either way, I think DavidR has given the solution.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 23:00 Edited at: 9th Jul 2008 23:02
Really? o_o

David R - MS:VS threw a hissy fit:



I don't need to as the data is never actually accessed from memblock and is just over written when the program comes around to using the file extraction again.

dark coder - No, it's a character pointer and as far as I am aware Char*'s can place their information, like "Ludo" for example into strings no trouble. That, as far as I can see is what's going on here.

What are you talking about char arrays? The thing is declared as a:

char* Memblock ;

Not an array.

Additionally I have tried opening the file without the binary arguments and it makes no difference to the output, the weird bit on the end of the memblock char* data is still there.

And I wrote that before seeing your edit.

We are here and it is now.
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 23:02
Quote: "David R - MS:VS threw a hissy fit:"


Yeah, that was a moment of my memory failing me - it isn't ios::text - just get rid of ios::binary and it defaults to text


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 23:02
Quote: "Additionally I have tried opening the file without the binary arguments and it makes no difference to the output, the weird bit on the end of the memblock char* data is still there."


We are here and it is now.
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 23:05
Quote: "Additionally I have tried opening the file without the binary arguments and it makes no difference to the output, the weird bit on the end of the memblock char* data is still there"


Either way, leave ios::binary out of it, you don't want or need it because you're not dealing with binary data


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 9th Jul 2008 23:05 Edited at: 9th Jul 2008 23:08
@Ludo

Edit: Request (size + 1) for your new statement then
/Edit

Once you read in the data that memblock points to, try putting in a line of code that states:

*(memblock + size) = '\0';

and see if that doesn't fix your problem. This line should follow either

Scribe->read ( memblock, size );

or

Scribe->close();

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 23:05
Quote: "What are you talking about char arrays? The thing is declared as a:

char* Memblock ;

Not an array."

I think it would be a good idea to read a C++ tutorial such as the one I linked to before.

David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 23:07
Quote: "I think it would be a good idea to read a C++ tutorial such as the one I linked to before.
"


I second this.


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 23:14 Edited at: 9th Jul 2008 23:15
Lilith - Alright, the prize goes to Lilith for providing a concise, easy to use and, above all, working answer to the problem!

I put that in:



And now even memblock put into dbText() isnt showing an error. Thanks Lil.

Benjamin - The thing is a char array which is created via a pointer isn’t it. I guessed that much but it is a pointer technically.

David R - I might as well remove it as it doesn’t have any effect on the process if it's there or not.

We are here and it is now.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 9th Jul 2008 23:21 Edited at: 9th Jul 2008 23:22
Quote: "working answer to the problem!"


Almost working, you're actually overwriting the char past the end of your array in your read file data, besides isn't this and the fix to this exactly what I said in my first reply?

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 23:21
Your buffer isn't big enough, add an extra byte to it.

Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 23:27
Benjamin/dark coder - Check the output in the screenshot, the data is all there and the last char is a ¬ so I don't need to do anything.

dark coder - Probably but I didn't understand it so I ignored it (I think) and I've never seen Lil's code before so hers was a concise and easy to use answer. Sorry.

Anyway, it's all good, all working. Go comment on my method now.

We are here and it is now.

Attachments

Login to view attachments
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 23:29
Wow, is that your way of thinking? If it works for you at the time, then that's how it should be done?

Look, you can't do this:

char buffer[5];
buffer[5] = 0;

The buffer is 5 bytes big, and 5 accesses the sixth byte of the array, which doesn't exist. It may not crash sometimes, but it's wrong.

Matt W
18
Years of Service
User Offline
Joined: 4th Mar 2006
Location:
Posted: 9th Jul 2008 23:33
memblock = new char [size+1] ;

?
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 9th Jul 2008 23:34
I actually had modified my post to include the extra byte. I suspect that it was a few seconds after the post was read.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jul 2008 23:35
Ludo
16
Years of Service
User Offline
Joined: 23rd Jun 2008
Location: UK, Oxfordshire
Posted: 9th Jul 2008 23:35
Quote: "Wow, is that your way of thinking? If it works for you at the time, then that's how it should be done?"


No, I believe that if something works once, it will work again. It's the basis of human thought processes; that something causes something else to occur and if good things happen then it should be done again.

I know you can't do that because the last slot don't exist. Arrays count from 0-4 but are declared as 5, for a start.

What's your point?

And I never try and access anything outside of each 15 data elements, divided by ¬ within the s string of my code, as I have code quoted a few times now.

We are here and it is now.
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 9th Jul 2008 23:36
Quote: "Benjamin/dark coder - Check the output in the screenshot, the data is all there and the last char is a ¬ so I don't need to do anything."


Compile it release mode, I want to watch it crash


09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0

Login to post a reply

Server time is: 2024-09-30 03:35:50
Your offset time is: 2024-09-30 03:35:50