We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now


Nonstandard extension used

Chris_m asked
Medium Priority
Last Modified: 2008-03-17
When compiling my program, the following line of code causes a warning which I list after the code.

Escape(hdcPrn, SETABORTPROC, NULL, (LPSTR)lpAbortProc, (LPSTR)NULL);

This generates the following warning:

C4001 non standard extension used - 'cast of function pointer to data pointer'

Getting help on this warning gives the following:

C4001 non standard extension used - 'extension'
The given non standard language extension was used when the /Ze option was specified.
If the /Za option has been specified, this condition generates a syntax error. (warning levels 1, 4)

What can I do to overcome this?
Watch Question

The 4th parameter (LPSTR)lpAbortProc causes the warning.
Apparently, lpAbortProc is a pointer to a function. You are
casting it a pointer to string (data). This is dangerous, since
the memory pointed by lpAbortProc may not contain valid string
data (7 bit characters, terminated by '\0'). This memory
contains the code of the function.
Make sure that lpAbortProc is indeed the correct argument to
this function. If you are trying to pass the *name* of the
function (for example "MyAbortFunc") than this will not work. If
this is what you are trying to do, you need to save the name
somewhere *as a string* and pass that string.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

I you are using a C++ compiler to compile your C program then you  will get this warning with the /Ze option , because the microsoft extension has been  enabled . You may get same warning if you use  Single line comment  "// " in a C code . You can disable this warning by inserting the
          #pragma warning(disable:4001)
into your code.


lpAbortProc is a FARPROC data type and is a procedure instance address returned by a MakeProcInstance function.  I have coded the same as described by Peter Norton on page 726 of Eindows 3.1 Power Programming Techniques, 2nd edition; and page 912 of Petzolds Programming under Windows 3.1.  The Petzold book that I use is the german edition, so the english edition may have the example on a different page.
The code is as follows:
lpAbortDlg = MakeProcInstance((FARPROC)AbortPrintDlg, hInst);
hDlgAbort = CreateDialog(hInst, "Abort Print", (FARPROC)lpAbortDlg);
lpAbortProc = MakeProcInstance((FARPROC)PrintAbortProcedure, hInst);
Escape(hdcPrn, SETABORTPROC, NULL, (LPSTR)lpAbortProc, (LPSTR)NULL);

FARPROC is a pointer to a function. If you check the memory
pointed by it you will find the machine instructions of the
LPSTR is a pointer to a null terminated text string. It should
point to a buffer that contains 7-bit characters, terminated by
the null character '\0'.
The is a very little chance that the machine instructions of the
function also happen to be 7-bit characters terminated by '\0'.
This means the the code probably contains an error, and that
the compiler is right to issue a warning.
It is strange that such an example appears in Petzold. Maybe you
should check the errata, or the English version.
You can try changing the cast from (LPSTR)lpAbortProc to
(FARPROC)lpAbortProc - maybe that is the typo.


I changed the cast to (FARPROC) lpAbortProc but that produces two warnings, namely:

    different levels of indirection
    ESCAPE: different types: parameter 4

I have tried all sorts of things -- apart from changing compiler switches --  to no avail.  By the way, I have a third book which uses the same code for the SETABORTPROC Escape.


I wrote:

> You can try changing the cast from (LPSTR)lpAbortProc to
> (FARPROC)lpAbortProc - maybe that is the typo.

And may a typo myself! This should have been:

Hope this helps.


I have been on holiday, appologies for the delay.
If I make the cast (FARPROC*)lpAbortProc, I get the C4001 warning again.

Attention ramshank: I will disable the warning as a last resort, but I am really interested in what is causing the warning. What is interesting is that the the same cast is used in other Escape calls without provoking a warning.


Adjusted points to 300

What is the declaration of lpAbortProc?
Can you cast it to FARPROC* without getting warning C4001
somewhere else in your program?


The declaration is
  FARPROC  lpAbortProc

I cannot cast it to FARPROC* anywhere else in the program without getting warning C4001

Aha - try to pass &lpAbortProc instead of lpAbortProc.

Hope this solves your problem.


Do I understand you correctly?  If you want me to change the declaration frpm FARPROC lpAbortProc to
FARPROC &lpAbortProc, then this does not compile.            

No, the declaration remains the same. But instead of passing
lpAbortProc as an argument to Escape(), try passing &lpAbortProc:

Escape( hdcPrn,
        &lpAbortProc, // this is what I mean


When I do what you suggest, the program compiles without giving a warning, but, when running a General Protection Fault (Trap 13(0DH)is caused.

Try checking for the validity of hdcPrn and lpAbortProc before calling Escape().


The validity of hdcPrn and lpAbortProc is ok

Maybe the GPF is caused by some other piece of code?

You can try putting trace statements before Escape(), after Escape() and inside PrintAbortProcedure() to see when the GPF actually occurs.


The GPF occurs as soon as the PrintAbortProc() function is called.  I put a breakpoint on the first line of code in the function and got a GPF.  With a breakpoint before calling PrintAbortProc(), no GPF.

OK, how is PrintAbortProcedure defined?


BOOL FAR PASCAL PrintAbortProc(HDC hdcPrn, short code)
MSG msg;

while(!bUserAbort && PeekMessage(%msg, 0, 0, 0, PM_REMOVE)){
if(!hDlgAbort || !IsDialogMessage(hDlgAbort, &msg)) {
return !bUserAbort

Seems fine. Just to make sure: Try passing &PrintAbortProc instead of &lpAbortProc, since MS now say not to use MakeProcInstance().
It shouldn't make a difference, but it's worth a check.


I am not sure that I understand what you mean.

The documuentation for MakeProcInstance sais:

"The MakeProcInstance function is obsolete. Win32 functions can be called directly.
This function is provided only for compatibility with 16-bit versions of Windows. Win32-based applications should not use this function."

So it may be a good idea to use the function address directly, instead of using MakeProcInstance.


I am using a 16 bit version of windows so I must continue using the MakeProcInstance function.

Sorry. I give up.

Godd luck!
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.