On Sun, Jan 29, 2012 at 12:46 PM, Pete Batard <[email protected]> wrote:
> This one is fairly straightforward, but I'll sent it to the list > nonetheless. > > The issue here is that when not compiling a C++, MSVC compilers do not > accept variables to be defined after code, and the MMC_CMD_SETUP() macro > does define a cdb variable. > Yes, the intention is have all declarations in a come before statements as C99 wants. So thanks. It is possible I'll merge this into trunk sooner than the rest. > Moving the macro to only occur after the variable definition block should > be risk free, as the macros moved do not reuse any variable that may be > uninitialized (besides, it's really a variable init macro, so it should > probably intervene at the top always). > > There's an additional bunch of minor MSVC related patches that I'm not > planning to send or mention to the list as they are minor. Please see > http://git.savannah.gnu.org/**gitweb/?p=libcdio.git;a=** > shortlog;h=refs/heads/pbatard<http://git.savannah.gnu.org/gitweb/?p=libcdio.git;a=shortlog;h=refs/heads/pbatard>for > details. > > With this out of the way, MSVC support should now be smooth sailing (I > have already tested the remaining patches for MSVC, but they need a bit of > cleanup). > > Regards, > > /Pete > > > > > From 2331026997aa87ae14999cd91a13c2097c3e0122 Mon Sep 17 00:00:00 2001 > From: Pete Batard <[email protected]> > Date: Sun, 29 Jan 2012 17:07:23 +0000 > Subject: [PATCH 3/3] Fix mmc_ll_cmds.c for use with MSVC compilers > > * The MMC_CMD_SETUP() macro defines a new variable 'cdb' > * When using C mode, MSVC compilers do not accept variables to be > defined after code > --- > lib/driver/mmc/mmc_ll_cmds.c | 13 +++++++------ > 1 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/lib/driver/mmc/mmc_ll_cmds.c b/lib/driver/mmc/mmc_ll_cmds.c > index 7a92ea6..e94dcd8 100644 > --- a/lib/driver/mmc/mmc_ll_cmds.c > +++ b/lib/driver/mmc/mmc_ll_cmds.c > @@ -297,11 +297,11 @@ mmc_read_cd(const CdIo_t *p_cdio, void *p_buf1, > lsn_t i_lsn, > uint8_t cdb9 = 0; > const unsigned int i_timeout = mmc_timeout_ms * (MAX_CD_READ_BLOCKS/2); > > + MMC_CMD_SETUP(CDIO_MMC_GPCMD_READ_CD); > + > /* Catch what may be a common bug. */ > if (NULL == p_buf) return DRIVER_OP_BAD_POINTER; > > - MMC_CMD_SETUP(CDIO_MMC_GPCMD_READ_CD); > - > CDIO_MMC_SET_READ_TYPE(cdb.field, read_sector_type); > if (b_digital_audio_play) cdb.field[1] |= 0x2; > > @@ -397,10 +397,10 @@ mmc_set_speed(const CdIo_t *p_cdio, int i_Kbs_speed, > unsigned int i_timeout_ms) > uint8_t buf[14] = { 0, }; > void * p_buf = &buf; > const unsigned int i_size = sizeof(buf); > - if (0 == i_timeout_ms) i_timeout_ms = mmc_timeout_ms; > - > MMC_CMD_SETUP(CDIO_MMC_GPCMD_SET_SPEED); > - > + > + if (0 == i_timeout_ms) i_timeout_ms = mmc_timeout_ms; > + > /* If the requested speed is less than 1x 176 kb/s this command > will return an error - it's part of the ATAPI specs. Therefore, > test and stop early. */ > @@ -464,7 +464,8 @@ mmc_test_unit_ready(const CdIo_t *p_cdio, unsigned int > i_timeout_ms) > { > const unsigned int i_size = 0; > void * p_buf = NULL; > - if (0 == i_timeout_ms) i_timeout_ms = mmc_timeout_ms; > MMC_CMD_SETUP_READ16(CDIO_MMC_GPCMD_TEST_UNIT_READY); > + > + if (0 == i_timeout_ms) i_timeout_ms = mmc_timeout_ms; > return MMC_RUN_CMD(SCSI_MMC_DATA_NONE, i_timeout_ms); > } > -- > 1.7.8.msysgit.0 > > >
