[Mingw-notify] [ mingw-Bugs-2541233 ] Compilation Error because of incomplete header file

[SourceForge.net <no...@so...>]

Bugs item #2541233, was opened at 2009-01-27 15:18
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2541233&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: w32api
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Oliver Kreis (okdev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compilation Error because of incomplete header file

Initial Comment:
Hi,

in header sspi.h a include of ntdef.h is missing, because UNICODE_STRING is undefined.

So long.

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2009-01-30 08:50

Message:
<blockquote>Issues such as this then beg the question: how far do we go, to
ensure
that w32api headers are compilable in isolation? ntdef.h itself has
dependencies on other types, which are typically defined by including
windows.h, yet we don't normally include that automatically; we expect
the
user to fulfill that prerequisite for us.</blockquote>

Tai had a response recently that he wished we do emulate as much as we do.
 If we add the proper turn off mingw extensions filter around the include,
then I say we should.  As Tai also pointed out, we're already beyond
minimal, I think it is good practice to circumvent the issue.

----------------------------------------------------------------------

Comment By: Keith Marshall (keithmarshall)
Date: 2009-01-30 07:28

Message:
And we've had a very similar report recently, in
https://sourceforge.net/tracker2/?func=detail&aid=2149002&group_id=2435&atid=102435,
wrt security.h

That was closed as invalid, due to lack on any documentary evidence that
security.h *should* include ntdef.h;
http://msdn.microsoft.com/en-us/library/aa492030.aspx says that, to use
UNICODE_STRING *you* should #include wdm.h or ntddk.h, so presumably either
of those is a prerequisite for sspi.h, (which does assume that
UNICODE_STRING is previously defined).

Clearly, sspi.i is uncompilable without a prior definition of
UNICODE_STRING, but MinGW provides neither wdm.h, nor ntddk.h.  Including
ntdef.h from sspi.h may be an effective way to circumvent the issue, (and
it would also resolve the previously reported issue with security.h), but
is it the correct solution?  I just don't know for sure; maybe we should
just do it as a necessary hack, (with an appropriate comment to explain why
it has to be there)?

Issues such as this then beg the question: how far do we go, to ensure
that w32api headers are compilable in isolation?  ntdef.h itself has
dependencies on other types, which are typically defined by including
windows.h, yet we don't normally include that automatically; we expect the
user to fulfill that prerequisite for us.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2541233&group_id=2435