[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] modifications of ISO9660 and UDF headers for MSVC

From: Pete Batard
Subject: Re: [Libcdio-devel] modifications of ISO9660 and UDF headers for MSVC
Date: Tue, 31 Jan 2012 14:23:22 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

Hi Robert,

On 2012.01.31 11:27, Robert William Fuller wrote:

A flashback from my Windows NT driver writing days:  I seem to recall
that MSVC will allow "char str[0]" here.  You can have a zero-length
array at the end of a structure as long as the size is explicitly zero.
  It's just done with "str[0]" instead of "str[]"?

Yes, MSCV has some partial support for zero-length when they are placed at the end of a struct, and either [0] or [] can be used (accepts both).

So the MSVC fixes do not remove zero-sized arrays altogether. In fact, most the of the existing zero-sized arrays from the code have been left untouched.

The only issue I've had to address are sequences of multiple zero sized arrays or zero sized arrays at the end of a struct when this struct itself is used in the middle of another struct, as MSVC doesn't support this usage.

For the first case, I added an union of multiple zero-sized arrays (eg. [1], which MSVC has no problem with) and for the second case, an union with a nonzero element (there's only one place where I had to do that: [2]).

I'm hoping that these changes will cause minimal disruption enough to be integrated into the next version of the API. The only annoyance is with having to deal with a string that is not zero indexed. The other option, to avoid a non zero indexed string would be to add a struct for the string within the union, with a one byte padding, but that would add an extra indirection => p_iso9660_dir->filename.s.str[0] vs p_iso9660_dir->filename.str[1].

If someone thinks having an extra struct to avoid a non zero indexed string is the better approach, I can amend the patch.



[1];a=blob;f=include/cdio/ecma_167.h;hb=4d2c961cf1eaf68090b1dea51c86fc9f9ecf9415#l492 [2];a=blob;f=include/cdio/iso9660.h;hb=4d2c961cf1eaf68090b1dea51c86fc9f9ecf9415#l276

reply via email to

[Prev in Thread] Current Thread [Next in Thread]