libcdio-devel
[Top][All Lists]
Advanced

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

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


From: Rocky Bernstein
Subject: Re: [Libcdio-devel] Fix mmc_ll_cmds.c for use with MSVC compilers
Date: Sun, 29 Jan 2012 21:24:58 -0500

On Sun, Jan 29, 2012 at 12:46 PM, Pete Batard <address@hidden> 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 <address@hidden>
> 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
>
>
>


reply via email to

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