Re: [Libcdio-devel] Fix mmc_ll_cmds.c for use with MSVC compilers

[Rocky Bernstein]

On Mon, Jan 30, 2012 at 11:47 AM, Pete Batard <address@hidden> wrote:

> On 2012.01.30 14:53, Robert Fuller wrote:
>
>> This brings up an important point.  MSVC
>> does not support C99 and Microsoft has no stated plans to support it.
>>
>
> Unfortunately, that's absolutely true. That's also why trying to reuse
> C99/GNU99 code in an MSVC project can be a major PITA.
>
> Besides limitations with zero sized arrays,


There have been people on occasion who have wanted to compile libcdio using
Sun's native C compiler (Studio?) that have mentioned the zero-sized
arrays. Unlike you however, they gave up. But along the way they have moved
this closer to C89.


> even Visual Studio 2010's MSVC can still not use named initializers in
> structs, and despite the brand new addition of stdint.h at long last, it
> still lacks inttypes.h for instance.
>
>
>  That was one reason I chose not to support MSVC in my own ripper.  I
>> was taking advantage of some C99 features and the trade-off of
>> removing them to support MSVC was not worth it, for my project.
>>
>
> As far as libcdio is concerned, not much was actually needed to achieve
> MSVC support.


Good to hear. A systems administration principle which is relevant here:
never ascribe to maliciousness (in this case lack adherence to C89) that
which can easily be attributed to oversight.

This MMC minor fix, for mixed var init and code, and the update for zero
> sized arrays are pretty much the only visible constraints that had to be
> applied to common code. But I guess most of this is due to the effort of
> people who kept existing code MSVC friendly until not so long ago.


Yep. Solaris and XMBC folks I think were very helpful.


> Other projects might not be so lucky...
>
> If your MSVC user base is expected to be limited, and you have adequate
> support for MinGW, I can understand why ditching MSVC would make sense, as
> it will definitely save you time.
>
> Regards,
>
> /Pete
>
>