String length and padding of offset 0x3d00

[PhilippM]

Hi Pete,

simple question: how to obtian the string length of the aircraft name?

At the moment, I'm doing something like this:

std::string title;
title.resize(256);
FSUIPC_read(0x3d00, 256, &(title[0]), &error);

which yields a string like

title == "Cessna 172 (white space characters until 256) "

Simple matter, just apply some trim function to the string and get rid of the spaces.

I tried:

#include 

boost::algorithm::trim(title);

and also

void trim(std::string& str)
{
    std::string::size_type pos = str.find_last_not_of(' ');
    if(pos != std::string::npos) 
    {
        str.erase(pos + 1);
        pos = str.find_first_not_of(' ');
        if(pos != std::string::npos) 
            str.erase(0, pos);
    }
    else 
        str.erase(str.begin(), str.end());
}

trim(title);

but whatever I try, title is always displayed as "Cessna Skyhawk (many spaces) ".

What kind of padding characters are these, that fill up to byte 256? The fact that I can't get rid of them by trimming whitespaces, these appear to be not the ASCII " " character. Can you confirm the string is in fact a C-String?

Philipp

[Pete Dowson]

simple question: how to obtian the string length of the aircraft name?

I just use the standard "strlen" function, which does a compact loop looking for the first zero byte (which is how ASCIIZ strings are terminated by definition).

At the moment, I'm doing something like this:

std::string title;
title.resize(256);
FSUIPC_read(0x3d00, 256, &(title[0]), &error);

which yields a string like

title == "Cessna 172 (white space characters until 256) "

Really? What you call "white space" should be zeroes, which are NULLs in ASCII. Although there is no guarantee that there will be any more than one byte of zero, to terminate the string. The rest might be rubbish from a previous longer name.

... whatever I try, title is always displayed as "Cessna Skyhawk (many spaces) ".

Sorry, I don't know what language you are using nor how it manasges to interpret a zero terminator for a standard Windows ASCIIZ string as a space, let along so many of them.

What kind of padding characters are these, that fill up to byte 256? The fact that I can't get rid of them by trimming whitespaces, these appear to be not the ASCII " " character. Can you confirm the string is in fact a C-String?

Of course. It is a standard zero-terminated ASCII string, usually termed as ASCIIZ. Exactly as used universally in C and C++. You should certainly not be using any characters past the first zero.

Pete

[PhilippM]

I just use the standard "strlen" function, which does a compact loop looking for the first zero byte (which is how ASCIIZ strings are terminated by definition).

Hmm, apparently either me or my compiler misinterprets what "contiguous memory" means, cause this is what the string is guaranteed to be stored in, according to the C++03 Standard. I tried a strlen on title.c_str() and got 256. Hmm.

Given the fact that substantially more people work on my compiler, I think the mistake is on my side :(

Really? What you call "white space" should be zeroes, which are NULLs in ASCII. Although there is no guarantee that there will be any more than one byte of zero, to terminate the string. The rest might be rubbish from a previous longer name.

Sounds reasonable, but apparantly I'm not getting this 0x0-character.

Sorry, I don't know what language you are using nor how it manasges to interpret a zero terminator for a standard Windows ASCIIZ string as a space, let along so many of them.

This is all C++/STL.

Of course. It is a standard zero-terminated ASCII string, usually termed as ASCIIZ. Exactly as used universally in C and C++. You should certainly not be using any characters past the first zero.

This is exactly what I expected. It's just that I don't get a terminating 0 when reading it into memory.

Thanks for fast reply, I'm going to digg deeper.

[PhilippM]

Ahhhh... I got the error.

I didn't remeber the "contiguous memory" thing correctly. I had to look it up in my copy of "Effective STL". std::vector is guaranteed to be stored in contiguous memory, std::string is not. So the trick is to read the bytes into a std::vector and then construct the string from the iterators. What I was seeing was the result of undefined behaviour: std::string reserved a 256 character string made of whitespaces and then some of the bytes got overwritten by this call. Nevertheless, the string was 256 characters long from the C++ standpoint.

Sorry for the hickup. I always stumble over those easy things at the border line between C and C++, because these languages ARE different.

Thank you for the fast answer, good nite :)

Philipp

[Pete Dowson]

Hmm, apparently either me or my compiler misinterprets what "contiguous memory" means, cause this is what the string is guaranteed to be stored in, according to the C++03 Standard. I tried a strlen on title.c_str() and got 256. Hmm.

Very curious. And this is for all aircraft?

The same string is logged in the standard FSUIPC Log file, merely using a normal printf with the %s string selector.

Sounds reasonable, but apparantly I'm not getting this 0x0-character.

What you are getting can easily be logged -- check the "IPC read" logging option in FSUIPC Logging options.

Regards

Pete

[PhilippM]

Whew, you should be nominated for the "fastest support ever"-award. :)

[Pete Dowson]

Whew, you should be nominated for the "fastest support ever"-award. :)

But the next response might take longer. I'm off to bed now! ;-)

Pete