If you XOR the string with itself byte--by-byte, it will consist of only 0 bytes. Since it's all a known length of zeroes, you just need to store the length. Then, at runtime, you just need to allocate the length amount of space on the stack and XOR it once again with the original string, and voila, no need to store the string in the DATA segment, it can go in the BSS segment instead.
It's called the "turtles all the way down" method.
If your strings are so similar, why can't you generate them at run-time?
::sprintf_s( szBuffer, MAXLEN, "Some very long string %u . ..", ui32Index );Or similar. This sounds as though this problem is meant to be tackled via out-of-the-box thinking rather than by working around computer-science issues.
For what it's worth, using constant strings as just pointers into a data section is reliable enough that it is used in ASKA Engine (tri-Ace) to implement "print-once" error messages. To avoid spamming the console, the string pointer is kept, not an actual copy of the string. This is important for run-time as we do need running builds of the games that also print (or silence) debug messages quickly. So you will use a macro such as "ASSERT_ONCE( someCondition, "The condition failed. Checkmate, atheists." )", and as long as "pool strings" is set then this string pointer will have 1 pointer no matter where it is used, so redundancy checks on the string can be done just by checking the pointer, not the string.
This has been very tested over many years and is reliable on all consoles and relevant platforms (and most irrelevant platforms), however do keep in mind that it is only used for debug purposes, as it is not guaranteed by the standard. Code that relies on this should not be put into the wild.
L. Spiro
10 hours ago, Bregma said:If you XOR the string with itself byte--by-byte, it will consist of only 0 bytes. Since it's all a known length of zeroes, you just need to store the length. Then, at runtime, you just need to allocate the length amount of space on the stack and XOR it once again with the original string, and voila, no need to store the string in the DATA segment, it can go in the BSS segment instead.
It's called the "turtles all the way down" method.
? Thanks
I agree with @rnlf_in_space that I should not but I never done something like this and I just need to try it.
I can't say that I'm much of that expert, wouldn't some code immediately when it encounters " " store the string in read-only segment if it's long enough or store it in an instruction if it's short enough as commented in previous posts?
Could you please show me how would you do it?
3 hours ago, L. Spiro said:If your strings are so similar, why can't you generate them at run-time?
::sprintf_s( szBuffer, MAXLEN, "Some very long string %u . ..", ui32Index );
I didn't know I can do this. I red a bit about ::sprintf_s() in the documentation. I see it stores some string into some buffer, that is szBuffer. But what I don't understand is if I write it like you did, wont "Some very long string %u . .." be immediately stored in read-only segment, before I even call this function, at least the part "Some very long string" without %u?
You need to be familiar with printf, sprintf, and related functions if you are going to be a programmer. All the information on what they do and how they behave is very heavily documented.
In my example, szBuffer is a local heap buffer (or you could allocate with new [] and free later with delete []) and MAXLEN is the length of that buffer. It should be long enough to handle the longest possible string you could put into it. If it goes over 1024 bytes you should strongly consider allocating szBuffer rather than putting it on the stack.
The source string ("Some very long string %u . .." in this case) will exist once in your executable and then format-copied into szBuffer with the changes you make during the format.
The rest you have to learn on your own via the documentation.
L. Spiro
Oh sorry, I forgot that you were talking about similar strings. Somehow I thought that this way it wont go into exe file.
Just out of curiosity, if you don't want your strings stored in the exe, and you don't want to read them from a file, where exactly do you plan to get them from?
You're going away on an expedition to the south pole. Besides some stuff to protect yourself from the cold, you think you may get bored one evening, and you will need something to read duriing the evening/night.
Question: Can you do that without bringing a number of books with you?
My guess is, you cannot. The only things you have when you're at the south pole, is whatever you bring with you, and lots and lots of snow and ice.
A computer works is not the south pole, but it works a lot like it. If you give a program to someone to use, you must give everything that is required for functioning of the program. If you leave out a part, the computer cannot re-invent it, or wizard it out of thin air, just as much as you cannot read a book at the south pole that you left at the dinner table of your home, but forgot to pack.
@ryt, just to be clear, what @Bregma suggested is a joke. You see how they want you to "XOR with the original string"? That means you need to store that in your file.
2 hours ago, rnlf_in_space said:
Ok, thanks for clarifying that ?, it was strange to me though I was not sure it was possible.
Just to be clear I never intended to skip storing strings from an exe file. I started the topic based just of curiosity. When I red the link from the beginning and some other sources it was still not clear to me completely how strings were stored so I asked it here.
For e.g. the link mentioned that the strings could be stored in read-only segment or in some other place like in an instruction for small strings. So this was pretty undefined for me so I thought that there are also some other possibilities to store hard-coded temporary string literals.
I also thought that if we use a local temporary string that gets stored in an array that they wont be at all in read-only section but coded in an instruction or somehow else. Now I know that only smaller strings get stored in an instruction and that other get stored in read-only segment whatever we use, a pointer to it or an array.
