Guenter wrote:
>>>>> Why do you add the extra \0 in these strings?
>>>>
>>>> no idea - everyone does; seen in all .rc files so far.
>>
>> Check wine..
>
> I check nothing
You say everyone does, I mentioned a source which doesn't, and which
in my view would be a bit more reliable than others in this case.
> I do not care if there are some trailing \0 or not.
I think they're ugly, I don't think they make any sense, and I would
prefer if we didn't have them.
> They are in libcurl.rc, in cares.rc, in a couple of other
> OpenSource projects (see below), and now they are with libssh2.rc.
We might have had them before too.
> Other project's resource files where I see these trailing \0:
> Apache libapr:
> Apache httpd:
> Subversion:
> PHP:
Not much reason for us to keep them..
> With a quick googling I found M$ suggests them here:
> http://msdn.microsoft.com/en-us/library/aa381058%28v=VS.85%29.aspx
> look for:
> #define VER_FILEVERSION_STR "3.10.349.0\0"
> #define VER_PRODUCTVERSION_STR "3.10\0"
Interesting. It's too bad that we don't know the contents of the
other defines in that StringFileInfo BLOCK. But we can have a look at
the docs for StringFileInfo:
http://msdn.microsoft.com/en-us/library/aa381049(v=VS.85).aspx
In all the examples (in the table, per parameter) there's no trailing
\0 anywhere.
MS rc.exe has /n for zero-terminating STRINGTABLE strings. It seems
like they should also not have a final \0 from the docs:
http://msdn.microsoft.com/en-us/library/aa381050(v=VS.85).aspx
> I really wonder what you care at all about few trailing \0 which
> might or might not be required.
Again: ugly and stupid.
> But if you care that much for these then I suggest this:
> compile a helloworld.c with a helloworld.rc without \0, and
> compile this with MSVC6, MSVC9, MingW32, Watcom, Borland, LCC and
> their shipping resource compiler. Then check if all these 6 binary
> results display the version info from the .rc file correctly on
> W2000, WXP, Vista, W7. If this is true then go and remove them.
This is one approach, but I think it's the wrong approach for an open
source project. It's much more suitable for commercial products.
If we can easily test stuff of course we should. If we know that
something will break of course we should avoid that.
In this case we don't really know, and it seems like an improvement
in several ways, so I consider it fine to optimistically make the
change.
Hopefully nothing will break. If something breaks then we can easily
fix it and we'll have a data point which we can document and which is
actually relevant for our project.
> And finally: dont get me wrong - I wondered about these also when I
> saw them first time, and I'm in doubt too if they are needed, just
> like you ...
This isn't my first time seeing them. I question them every time. :)
> -- but other than you I dont care about because its not worth to
> proof it
I agree it's not worth the effort of proving it, but I disagree that
we need to do that.
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-08-20