Re: Beware of /Zp1 compiler option when compiling for X64
- From: alunw <alunw@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 27 Aug 2009 08:42:01 -0700
"RichK" wrote:
Using a structure packing other than the default of 8 will result in a wide
variety of problems.
This problems are not isolated to X64 compiles.
You will also encounter problems in 32-bit applications.
Are these listed anywhere? In particular is there are list of types that
have different sizes? I have always used Zp1 and my software works reliably
and well on all 32 bit Windows platforms including various CE versions with
hardware alignment restrictions. (It also used to run on various RISC type
Unix boxes). There have been occasions where various Win32 APIs have not
worked in the documented way for me or have leaked memory or been unreliable
but mostly these have been known problems that many other people have come
across, so I don't suppose they are related to use of /Zp1.
Looking at the latest SDK header files and the Feb 2003 version that I had
been using for the last few years, it seems that neither protected
SECURITY_DESCRIPTOR or SECURITY_ATTRIBUTES correctly. Problems will
definitely be worse with X64 because now pointers are 8 bytes, so there will
be many places where this makes a difference where previously it did not.
I am going to follow your advice about protecting the Windows SDK header
files. It's easy for me to to do that because I usually wrap windows.h with
another file anyway, to deal with just this kind of eventuality (it was
essential for porting to CE). In fact this will prompt me to make sure I
never again use windows.h directly.
It is disturbing to think that I may have been passing incorrectly sized
buffers to some Windows APIs for years without realising - in particular the
security APIs I used in my example don't have a size parameter or a size
element in their structures, so Windows is probably corrupting memory at that
point.
Judging by the number of results Google comes up with for error 998 in
connection with 64-bit Windows, I'd guess that mine is not the only bit of
software to be running into this kind of issue.
.
I'd advise preceding all #includes of SDK header files with
#pragma pack(push, 8)
And following all #includes of SDK header files with
#prama pack(pop)
"alunw" <alunw@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A1439A99-266F-4036-9DE5-F955DA0BC7D8@xxxxxxxxxxxxxxxx
I encountered a mysterious and frustrating error when I attempted to call
CreateFileMapping() in a native X64 program. Error 998 was returned for no
apparent reason. When I transferred the problem code to a small program it
worked fine.
Eventually I realised that the problem was caused by the compiler options
I
am using: it seems that despite the header files' being littered with
various includes to push and pop the packing some structures used with
various Windows APIs have a different size when compiled with Zp1 from
compilation with default packing.
For example SECURITY_DESCRIPTOR_MIN_LENGTH seems to change to 36 from 40,
and sizeof(SECURITY_ATTRIBUTES) seems to change from 16 to 24.
This doesn't seem to cause trouble when you initialise a security
descriptor
but it does cause trouble when you try to pass a SECURITY_ATTRIBUTES
structure to an API such as CreateFileMapping().
I attach a small program that exhibits the problem Try compiling it with
and
without /Zp1. I used the command line
cl -DWIN64 -DWIN32 -DX64 -Zp1 test.c -link advapi32.lib
#include <stdio.h>
#include <windows.h>
int main()
{
HANDLE master_handle;
static char c[SECURITY_DESCRIPTOR_MIN_LENGTH];
static PSECURITY_DESCRIPTOR psd = (PSECURITY_DESCRIPTOR)c;
static SECURITY_ATTRIBUTES sa =
{sizeof(SECURITY_ATTRIBUTES),(PSECURITY_DESCRIPTOR) c,0};
if (InitializeSecurityDescriptor(psd,SECURITY_DESCRIPTOR_REVISION) &&
SetSecurityDescriptorDacl(psd,TRUE,0,0))
printf("Hurray Created sa OK. Sizes are %Iu %Iu
%Iu\n",sizeof(c),sizeof(psd),sizeof(sa));
SetLastError(0);
master_handle = CreateFileMapping(INVALID_HANDLE_VALUE,&sa,
PAGE_READWRITE,0,14048,"Global\\dp4SM");
if (master_handle == 0)
{
printf("Cannot create file mapping %d\n",GetLastError());
return 1;
}
else
printf("File mapping created OK!\n");
return 0;
}
I'm using Microsoft SDKS\Windows\v6.1 and the compiler is version
15.00.21022.08 for x64 processor.
I'm not sure what I'm going to do about this issue yet. My code ought to
work without Zp1, but there are several thousand source modules, so not
using
this option is a bit risky. I may try to fix the SDK header files. Or
since I
usually don't include <windows.h> directly but wrap it with a header file
of
my own, I may just be able to sort things out in that.
- References:
- Prev by Date: Re: Beware of /Zp1 compiler option when compiling for X64
- Next by Date: Re: "<...> is not a valid Win32 application" error trying to run d
- Previous by thread: Re: Beware of /Zp1 compiler option when compiling for X64
- Index(es):
Relevant Pages
|
