Pete Batard
2016-Feb-24 13:02 UTC
[syslinux] [PATCH 3/5] installers: MSVC compatibility fixes
More MSVC compatibility fixes, for packed structures. NB: In case you are aware of the issues that may come with MS vs GCC packing, so far, I have not seen evidence of detrimental impact from using ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for MinGW), with regards to the sections of code I am using in Rufus. -------------- next part --------------
Gene Cumm
2016-Mar-06 13:13 UTC
[syslinux] [PATCH 3/5] installers: MSVC compatibility fixes
On Wed, Feb 24, 2016 at 8:02 AM, Pete Batard via Syslinux <syslinux at zytor.com> wrote:> More MSVC compatibility fixes, for packed structures. > NB: In case you are aware of the issues that may come with MS vs GCC > packing, so far, I have not seen evidence of detrimental impact from using > ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for > MinGW), with regards to the sections of code I am using in Rufus. > > From 13b39c1f113a8bc5621249db21a382a689aa174e Mon Sep 17 00:00:00 2001 > From: Pete Batard <pete at akeo.ie> > Date: Tue, 23 Feb 2016 19:57:28 +0000 > Subject: [PATCH 3/5] installers: MSVC compatibility fixes > > --- > libinstaller/syslxint.h | 13 ++++++++++++- > libinstaller/syslxmod.c | 3 ++- > 2 files changed, 14 insertions(+), 2 deletions(-) >> diff --git a/libinstaller/syslxmod.c b/libinstaller/syslxmod.c > index 0ec4164..7bf4d91 100644 > --- a/libinstaller/syslxmod.c > +++ b/libinstaller/syslxmod.c > @@ -41,7 +41,8 @@ static void generate_extents(struct syslinux_extent _slimg > *ex, int nptrs, > unsigned int len; > > base = addr; > - len = lba = 0; > + len = 0; > + lba = 0; > > memset_sl(ex, 0, nptrs * sizeof *ex);Did Visual Studio actually complain about this one? -- -Gene
Pete Batard
2016-Mar-06 15:47 UTC
[syslinux] [PATCH 3/5] installers: MSVC compatibility fixes
On 2016.03.06 13:13, Gene Cumm wrote:> Did Visual Studio actually complain about this one?WDK compiler (which I also use) if I recall correctly. At any rate, some older compilers do not like double initializations like this one, and I don't think this change should be much of a contention point, since it doesn't introduce any liability. Regards, /Pete