filemanage Save Error

[devilsclaw]

since i have wx with debugging I get certain errors which i have no problem getting since they should eventually get fixed.

in filemanager.cpp

Code

    if(f.Write(mark, mark_length) != mark_length)
        return false;

this code causes an error.

I did a message box and the mark_length is 0

the error is caused by the f.write no biggy i can make a proper if statement to fix it but what im confused about is

!= mark_length

this means if it has nothing it return false. on my system that would mean i would not ever be able to save anything.

i changed it to this.

Code

    if(mark_length)
    {
       f.Write(mark, mark_length);
    }

but im not sure if its supposed to return false or not and what would need to be change in order to have it write the mark header correctly
if it really should be returning if mark_length is 0

so you dont have to look at the code in the file here is whats above it

Code

    char* mark = NULL;
    size_t mark_length = 0;
    if (bom)
    {
        switch (encoding)
        {
        case wxFONTENCODING_UTF8:
            mark = "\xEF\xBB\xBF";
            mark_length = 3;
            break;
        case wxFONTENCODING_UTF16BE:
            mark = "\xFE\xFF";
            mark_length = 2;
            break;
        case wxFONTENCODING_UTF16LE:
            mark = "\xFF\xFE";
            mark_length = 2;
            break;
        case wxFONTENCODING_UTF32BE:
            mark = "\x00\x00\xFE\xFF";
            mark_length = 4;
            break;
        case wxFONTENCODING_UTF32LE:
            mark = "\xFF\xFE\x00\x00";
            mark_length = 4;
            break;
        case wxFONTENCODING_SYSTEM:
        default:
            break;
        }
    }

    if(f.Write(mark, mark_length) != mark_length)
        return false;

[TDragon]

Looking at the context of the function in question, it's clear that mark_length will be 0 when none of the cases in the preceding switch statement are matched. It would seem appropriate, in that case, not to write a BOM -- putting the f.Write() call inside of "if (mark_length) {}" makes sense.

Without even looking up the documentation for the Write() function, it's apparent that it returns the number of bytes that were successfully written. Therefore, the original code is checking that the correct number of bytes were written and, if not, returning false to indicate that an error occurred.

So an appropriate solution in this case would probably be to change

Code

if(f.Write(mark, mark_length) != mark_length)
    return false;

to

Code

if (mark_length > 0)
{
    if(f.Write(mark, mark_length) != mark_length)
        return false;
}

[devilsclaw]

Code

wxFile::Write

size_t Write(const void* buffer, wxFileOffset count)

Writes the specified number of bytes from a buffer.

Parameters:
buffer  -  A buffer containing the data.
count  -  The number of bytes to write.

Return value:
the number of bytes actually written

so that would mean that the mark_length does not get changed by the write and it is the return that tells you how much it wrote

so im guessing the code should look like this

Code

if (mark_length > 0)
{
    if(!f.Write(mark, mark_length) )
        return false;
}

[TDragon]

so im guessing the code should look like this

Code

if (mark_length > 0)
{
    if(!f.Write(mark, mark_length) )
        return false;
}

This incorrectly assumes that any nonzero value means the write was successful. wxFile::Write might return a number greater than 0 but less than mark_length. The original code would correctly detect, in that case, that the write wasn't fully successful, and return false.

[devilsclaw]

yeah that is true.. i guess it could write less or more then it should depending..

[Alturin]

How about this:

Code

if(mark_length && f.Write(mark, mark_length) != mark_length)
    return false;

This way it won't write anything when there's nothing to write?

[devilsclaw]

i found each compiler handles certain things differently.

bool hello = true;
wxFile f("myfile");
i know the MS compiler if you do a if statement if(!hello && f.write(_("2"),2) > 0)
since the hello is true it f.write does not get ran..

but the other day with the g++ for some reason there was a if statement that was like that and the code still got ran.

I dont know why and maybe i did something wronge but im pretty sure it was because how g++ compiled it.

so if f.write gets ran and it should not it might error.

but then again i might be wronge.. i will try to reproduce the probem i was running into and post it here.

[TDragon]

i found each compiler handles certain things differently.

bool hello = true;
wxFile f("myfile");
i know the MS compiler if you do a if statement if(!hello && f.write(_("2"),2) > 0)
since the hello is true it f.write does not get ran..

but the other day with the g++ for some reason there was a if statement that was like that and the code still got ran.

This is not the case. Both compilers implement an important part of the C++ language called "short circuit evaluation" or "lazy evaluation". If the value of the first operand of a logical operator (such as && or ||) can determine the result (i.e. "false" for &&, "true" for ||), the second operand is not evaluated. This is true for every modern compiler including both MSVC and GCC.

So an appropriate solution in this case would probably be to change

Code

if(f.Write(mark, mark_length) != mark_length)
    return false;

to

Code

if (mark_length > 0)
{
    if(f.Write(mark, mark_length) != mark_length)
        return false;
}

Apparently there's some part of my suggested code that you think is broken or incorrect; I assure you it's not.

With all due respect:
It's clear you're not familiar with the "ins and outs" of the C++ language. You'll end up writing a lot of code with good intentions, and then running into a lot of problems that, to more experienced developers, are simple mistakes simply fixed. I make no claims to speak for the official Code::Blocks developers, but I imagine it may be somewhat annoying to see the Code::Blocks Development forum filled with posts that have less to do with getting serious work done on C::B and more to do with you figuring out how C++ works.

[devilsclaw]

the original code was doing the line.getchar even though it was not supposed to
it was causing index access errors which is why i even edited it before i got to document it.

Original Code:

Code

    while (x >= 0 && (line.GetChar(x) == ' ' || line.GetChar(x) == '\t')) --x;

since this is for positions there is always a 0 position so 0 would not cause a index problem.
yet this code did.

the one in the while should be enough from everything i have ever know from coding
but this peice for some reason made me doubt what i knew.. it messed with me man.

New code:

Code

    if(x >= 0) //have to make sure or it causes errors
    {
       while (x >= 0 && (line.GetChar(x) == ' ' || line.GetChar(x) == '\t')) --x;
    }

[Biplab]

With all due respect:
It's clear you're not familiar with the "ins and outs" of the C++ language. You'll end up writing a lot of code with good intentions, and then running into a lot of problems that, to more experienced developers, are simple mistakes simply fixed. I make no claims to speak for the official Code::Blocks developers, but I imagine it may be somewhat annoying to see the Code::Blocks Development forum filled with posts that have less to do with getting serious work done on C::B and more to do with you figuring out how C++ works.

@TDragon

I fully agree with you.

@devil....

Please don't fill up the Developer forum with your crappy patches. I've tested some of your patches and they break more than they fix.

IMO, you are trying to show that Code::Blocks's 0.25 million lines of code is mere crap and is broken.

The problem is you are reading few lines of code and making 100 lines of comments. Try to understand why that piece of code is there and if you remove it what will happen to the remaining code.

I'm sorry if my reply seems harsh. But I can't stop writing this. I'm sick of your posts.

My suggestion, if you find any bugs, report it in Berlios. If you have fixed that, post it in Berlios. We'll test it and apply.

Don't use this forum to post each and every piece of code you write.

In short, Please Don't Pollute the Forum.

[devilsclaw]

if the below comment was aimed at me it was missplaced since if you read the post i alread agreed with you.

Apparently there's some part of my suggested code that you think is broken or incorrect; I assure you it's not.

With all due respect:
It's clear you're not familiar with the "ins and outs" of the C++ language. You'll end up writing a lot of code with good intentions, and then running into a lot of problems that, to more experienced developers, are simple mistakes simply fixed. I make no claims to speak for the official Code::Blocks developers, but I imagine it may be somewhat annoying to see the Code::Blocks Development forum filled with posts that have less to do with getting serious work done on C::B and more to do with you figuring out how C++ works.

This comment was towards Alturin and if you look lower you will see why.

and the only reason why i made the below comment is because of the crappy,
undocumented Code Completion that tweaked my brain. the code asumes
everything is correct it has functions that can used for error checking
but are not. some areas it should not be since if its to flexible on
now it parses things you wont know whats causing the corrupted data
but in other areas it needs it.

i found each compiler handles certain things differently.

bool hello = true;
wxFile f("myfile");
i know the MS compiler if you do a if statement if(!hello && f.write(_("2"),2) > 0)
since the hello is true it f.write does not get ran..

but the other day with the g++ for some reason there was a if statement that was like that and the code still got ran.

I dont know why and maybe i did something wronge but im pretty sure it was because how g++ compiled it.

so if f.write gets ran and it should not it might error.

but then again i might be wronge.. i will try to reproduce the probem i was running into and post it here.

How about this:

Code

if(mark_length && f.Write(mark, mark_length) != mark_length)
    return false;

This way it won't write anything when there's nothing to write?

in most cases Alturin code would work fine. the only time that it would mess up is if for one you ran
out of hard drive space, the file is trying to get larger then the OS's / FileSystems
allows or if the file is not locked and someone deletes it. and finally stream or cpu glitch.

these are mostly not common but can happen.

the likely hood of it returning -1 or less when the documentation says it returns bytes written
it cant write negative values. the only way that would even be possible is if something
was accessing memory it should not be, but then again better safe then sorry.

@devil....

Please don't fill up the Developer forum with your crappy patches. I've tested some of your patches and they break more than they fix.

IMO, you are trying to show that Code::Blocks's 0.25 million lines of code is mere crap and is broken.

The problem is you are reading few lines of code and making 100 lines of comments. Try to understand why that piece of code is there and if you remove it what will happen to the remaining code.

I'm sorry if my reply seems harsh. But I can't stop writing this. I'm sick of your posts.

My suggestion, if you find any bugs, report it in Berlios. If you have fixed that, post it in Berlios. We'll test it and apply.

Don't use this forum to post each and every piece of code you write.

In short, Please Don't Pollute the Forum.

you are correct about my original patches. even said my self i was unsure.
and that why i have not posted another patch. everything else was tracing code down and pointing out the area.

but since i dont know the code as well as you who have been working on it for so long i was hoping for replies
in more detail so i could understand the coders intentions so that i would not fuck up like i did on the first
patches.

as for the other stuff i was just trying to be personalble and most of it i was asking for input.

[TDragon]

if the below comment was aimed at me it was missplaced since if you read the post i alread agreed with you.

Apparently there's some part of my suggested code that you think is broken or incorrect; I assure you it's not.

My mistake. This comment was unnecessary.

With all due respect:
It's clear you're not familiar with the "ins and outs" of the C++ language. You'll end up writing a lot of code with good intentions, and then running into a lot of problems that, to more experienced developers, are simple mistakes simply fixed. I make no claims to speak for the official Code::Blocks developers, but I imagine it may be somewhat annoying to see the Code::Blocks Development forum filled with posts that have less to do with getting serious work done on C::B and more to do with you figuring out how C++ works.

This one, I still stand by.

[Biplab]

Please read the following thread first.

http://forums.codeblocks.org/index.php/topic,1519.0.html

It has some general guidelines about what you should post here and what not to.

as for the other stuff i was just trying to be personalble and most of it i was asking for input.

The code and the sdk manual is open. Nothing is closed. Read them and understand them.

This is not a forum where you'll ask input for each and every nooks and corner of C::B's source. We can help you if it is really important. But you may not get any response if you ask questions which is NOT relevant to Code::Blocks.

... but I imagine it may be somewhat annoying to see the Code::Blocks Development forum filled with posts that have less to do with getting serious work done on C::B and more to do with you figuring out how C++ works.

I have the same feeling.

That's why my request to you: Don't Pollute the Forum.

[devilsclaw]

unfortunately since i started off as a Assembly programmer your correct i dont know c++ as well as i do it.

in a way c++ is more flexible then asm and in others its restrictive but for a reason. its to help people from making mistakes
those bounderies at the things that mess me up sometimes.

when i code my stuff i have no problems. but im not the greatest at reading other peoples code. which is why im trying to document the
parser.

i started off modding the internals of games and making them work better or implementing something the company should of.

I i know memory handling and pointers very well and i actually do understand my logic and i can code just fine with it.

i never expect any of my original stuff to be flawless when im first comming into something because fucking up is the bast way to learn.

i just dont want to mess other people up which is why im posting the stuff im looking at and working on in hopes of corrective input.

[thomas]

May I inquire as to the reason why a piece 100% reliably working code is disputed at all, and what "error" it is you see?

wxFile::Write calls wxWrite, which is a wrapper for WriteFile (http://msdn2.microsoft.com/en-us/library/aa365747.aspx) under Windows and fwrite (http://www.die.net/doc/linux/man/man2/write.2.html) on all other platforms.
Both OS Functions explicitely allow zero writes (implemented as no-op) and return the number of bytes actually written. wxFile::Write asserts that the data pointer is non-zero (which makes sense), but makes no assumptions about the size.

So, what exactly is your problem? What are we talking about, anyway?


The same goes for this:

the original code was doing the line.getchar even though it was not supposed to

It seems you really don't understand what is intended, nor what is actually happening (because your statement is wrong).