[Top][All Lists]

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

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

From: Pete Batard
Subject: [Libcdio-devel] Fix mmc_ll_cmds.c for use with MSVC compilers
Date: Sun, 29 Jan 2012 17:46:45 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

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.

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;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).



>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 
     uint8_t cdb9 = 0;
     const unsigned int i_timeout = mmc_timeout_ms * (MAX_CD_READ_BLOCKS/2);
     /* Catch what may be a common bug. */
     if (NULL == p_buf) return DRIVER_OP_BAD_POINTER;
     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;
+    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 
     const unsigned int i_size = 0;
     void  * p_buf = NULL;
-    if (0 == i_timeout_ms) i_timeout_ms = mmc_timeout_ms;
+    if (0 == i_timeout_ms) i_timeout_ms = mmc_timeout_ms;
     return MMC_RUN_CMD(SCSI_MMC_DATA_NONE, i_timeout_ms);

reply via email to

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