0

I am relatively new to Windows programming and this forum. As the title says, I'm getting this error whenever I try to run a particular C program I wrote. The program is compiled as x64 running on a 64-bit machine. Edit: After I press the OK button on the popup, I get an "Access is denied" message. The code, which I don't think has anything to do with the problem follows:

// CrtFil2.cpp : Defines the entry point for the console application.
//


#include "stdafx.h"
#include "string.h"

//#include BasInc2.c
//#include FilMst2.c

FILE * Opn(char PthNam[], char OpnMod[]);


void main()
{
    FILE    * FilMstFilPtr = NULL;

    FilMstFilPtr = Opn("\\temp\\test.file", "wb");
    printf("filptr=0x%p\n", FilMstFilPtr);
    return;
}

//******************************************************************************
//  Open a file.
//******************************************************************************
FILE * Opn(char PthNam[], char OpnMod[])
{
    FILE    * FilPtr = NULL;

    errno = fopen_s(&FilPtr, PthNam, OpnMod);
    if (errno != 0) {
        printf("%s\n", PthNam);
        perror("Could not open file");
        return NULL;
    }
    printf("file opened for mode %s\n", OpnMod);
    return FilPtr;
}

I got the following output on my build:

1>------ Build started: Project: CrtFil2, Configuration: Debug x64 ------ 1> CrtFil2.cpp 1> CrtFil2.vcxproj -> C:\$SmpSysLib\$QsysS\CrtFil2\x64\Debug\CrtFil2.exe ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

This worked until about an hour ago. Then I commented some lines and it quit working. I looked through the first 50 answers supplied on a search, and most of them involved running on XP or a particular 3rd party .exe. If this is a duplicate question, please let me know. A couple suggestions I tried were to shut down Visual Studio and restart it, and also shutting and restarting the PC. One answer pointed to this link: https://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-bit-on-windows. According to the answer, the .exe is compiled as a x86 application. However at the top of the VS display it says x64 as well as in the Property->Configuration Manager. This is on Visual Studio-2015 Community Edition Update 1.

I got the original program working even though the source code remained the same. But the same error cropped up on a different C program. I tried reinstalling VS but got an error when I tried to do it, so I'm somewhat stuck.

Is there a way to fix this problem?

Community
  • 1
  • 1
J. Toran
  • 157
  • 2
  • 2
  • 14
  • 1
    Unrelated to your problem, but the C specification says that `main` has to be declared in one of two ways, either as a function taking `void` arguments and returning `int`, or taking an `int` and a `char *[]` argument and returning `int`. If your `main` function does not do any of that, then it's technically an invalid program. – Some programmer dude Jan 12 '16 at 12:26
  • Thank you for the tip. I made the change, and as you suggested it didn't make any difference. – J. Toran Jan 12 '16 at 12:29
  • 1
    @JoachimPileborg It depends on which C standard is used. What's correct in the current standard, nobody really knows, because it has the vague "...or in some other implementation-defined manner" sentence. [See this](http://stackoverflow.com/a/31263079/584518) below "C99 hosted environment", with references to the C rationale and other parts of the standard. The committee themselves seem rather confused about this. – Lundin Jan 12 '16 at 12:34
  • @Lundin It's not like I have the specification on my nightstand and read it in bed (though it would be a good read to fall asleep quickly) so I didn't know about that. And I agree, "..or in some other implementation-defined manner" is beyond vague and really should not be in a formal specification like that. – Some programmer dude Jan 12 '16 at 12:41
  • @Lundin: There is only one C standard: C11. And that contains a footnote: http://port70.net/~nsz/c/c11/n1570.html#note10 (C99 containts the same footnote). – too honest for this site Jan 12 '16 at 12:41
  • @J.Toran Can you post build output window ? – Mohan Jan 12 '16 at 12:45
  • @Olaf That footnote applies to the sentence "or equivalent", rather than the releveant sentence "or in some other implementation-defined manner". It doesn't matter anyway, since foot notes are not normative in ISO standards, they just contain helpful advise and examples. – Lundin Jan 12 '16 at 12:47
  • @Mohan:`1>------ Build started: Project: CrtFil2, Configuration: Debug x64 ------ 1> CrtFil2.cpp 1> CrtFil2.vcxproj -> C:\$SmpSysLib\$QsysS\CrtFil2\x64\Debug\CrtFil2.exe ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========` – J. Toran Jan 12 '16 at 12:50
  • @Lundin: Yes, it elaborates the "equivalent". Anyway, _implementation defined behaviour_ must be documented by an implementation. For POSIX, IIRC, it is either of the two C standard versions or an extra argument after them. I don't know any hosted implementation which allows `void main( ...)`. – too honest for this site Jan 12 '16 at 12:51
  • @J.Toran i will suggest you change build location to other than c drive, check it and make sure you are running same debug .exe. – Mohan Jan 12 '16 at 12:56
  • @Mohan I only have a c: drive, and I don't know how to change the build location in VS. Also, I uncommented the 2 include files and added quotes, and it all of a sudden started working. I commented them again and it still worked OK. It very mysteriously stopped and started working for no reason I can determine. – J. Toran Jan 12 '16 at 13:11
  • @Olaf Visual Studio for example, allows `void main()`. This implementation-defined behavior is documented [here](https://msdn.microsoft.com/en-us/library/6wd819wh.aspx). – Lundin Jan 12 '16 at 13:45
  • @Lundin: I wish I get an Euro each time MS tools behave non-standard or unexpected ... OTOH, the C standard actually allow `main` to end without explicit `return` (but that is identical to `return 0;`). – too honest for this site Jan 12 '16 at 13:48
  • I don't know why the down vote on the question. The program worked, then it quit working for no reason. I researched it and tried some things and nothing worked. Then it started working for no reason. – J. Toran Jan 12 '16 at 13:54
  • In case anyone is interested, I got this same error on a different C program. I tried reinstalling VS, but it said the install required a newer version of Windows. I have Windows 7, so that message doesn't make any sense. – J. Toran Jan 12 '16 at 15:20
  • Agreed no reason to down vote. Moreover they are clearly spamming your post ;). Add the Build from the comment to the question and update the question with this new information. – terence hill Jan 12 '16 at 15:22
  • Do you have service pack 1 installed? – terence hill Jan 12 '16 at 15:27
  • @terence hill: Thank you. Also I do have service pack 1 installed. – J. Toran Jan 12 '16 at 16:02
  • Have you tried: 1. Rebuild All. 2. Restart Visual Studio (and do Rebuild All) 3. Disable any antivirus you have running ? – nos Jan 12 '16 at 16:04
  • @nos: I'm sorta new at this, so I don't know how to do a rebuild all. I have a doctors appointment, but I'll check back later. – J. Toran Jan 12 '16 at 16:20
  • In one of the include files of your project should be a setting for platform version number. Try to lower it or set it to appropriate value (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745%28v=vs.85%29.aspx). – Sergey Barannikov Jan 12 '16 at 17:08
  • I did a "Rebuild Solution" rather than a "Build Solution". The problem seems to be fixed (for now). – J. Toran Jan 12 '16 at 19:51
  • If you find a suitable solution, post it and accept it, see also https://blog.stackoverflow.com/2009/01/accept-your-own-answers/ – terence hill Jan 13 '16 at 10:25
  • @ terrence hill: Thank you. I tried to post the solution but it didn't show up. It didn't actually fix the problem because I got the same error in a different program. I'll post a new question with the new source, as I can reproduce the problem with it. – J. Toran Jan 13 '16 at 10:43
  • @ terrence hill: I take it back. Yesterday I could comment and uncomment some particular lines in this new source, and it would cause and fix the problem. That isn't the case today for some reason, so I'll not post a new question until I can do it consistently. – J. Toran Jan 13 '16 at 11:10

2 Answers2

0

this header file: #include "stdafx.h" is actually a composite compiled header of all the header files from that source file (and their dependencies).

If you were deleting #include statements during the editing, visual studio may have deleted that composite header file.

all the #include statements must be in the source file.

There are several ways to cause visual studio to delete that compiled header file. One way is to comment out the #include statements.

user3629249
  • 16,402
  • 1
  • 16
  • 17
  • How does this relate to the question? – Sergey Barannikov Jan 12 '16 at 18:58
  • the question is: why the 'not a valid 32bit executable. The most probable cause is the file did not actually cleanly compile. having no #include header files available is the most likely reason. Compiling with all the warnings enabled, then fixing those warnings – user3629249 Jan 12 '16 at 21:08
  • also related is the question says its' about C, but the filename `CrtFil2.cpp` says its' about c++. Two quite different languages. There is the strong possibility that visual studio is using the file name and trying to compile for C++ when the actual code is C. Given the error with the file name, I might also wonder if the project is designated as a `console` application or something else entirely. – user3629249 Jan 12 '16 at 21:11
  • @user3629249: In Visual Studio the source always comes up as CPP, but C code compiles just fine. There was no problem with the compile, just got this error when trying to run it. – J. Toran Jan 13 '16 at 10:44
0

it is best to write portable code, even if only going to run on windows.

so strongly suggest writing your C functions like so:

#define _CRT_SECURE_NO_DEPRECATE
//#include "stdafx.h
#include <stdio.h>
#include <string.h>
#include <errno.h>


FILE * Opn(char PthNam[], char OpnMod[]);


int main( void )
{
    FILE    * FilMstFilPtr = NULL;

    FilMstFilPtr = Opn("\\temp\\test.file", "wb");
    printf("filptr=0x%p\n", (void*)FilMstFilPtr);
    return 0;
}

//*****************************************************************
//  Open a file.
//*****************************************************************
FILE * Opn(char PthNam[], char OpnMod[])
{
    FILE    * FilPtr = NULL;

    #if 0
    errno = fopen_s(&FilPtr, PthNam, OpnMod);
    if (errno != 0) {
        printf("%s\n", PthNam);
        perror("Could not open file");
        return NULL;
    }
    #else
    if( NULL == (FilPtr = fopen( PthNam, OpnMod ) ) )
    {
        fprintf( stderr, "fopen failed for %s with mode: %s due to: %s\n", 
                 PthNam, OpnMod, strerror( errno ) );
    }
    else
        printf("file opened for mode %s\n", OpnMod);
    #endif
    return FilPtr;
}
user3629249
  • 16,402
  • 1
  • 16
  • 17
  • Just curious. In the compiler directives, what does `#if 0` check? – J. Toran Jan 13 '16 at 18:42
  • the `#if 0` `#else` and `#endif` are preprocessor directives. Any thing following a `#if 0` will be ignored until either a `#else` or `#endif` you might want to read: for further details on these (and other) preprocessor directives – user3629249 Jan 13 '16 at 19:09