C's FILE command

[clickit]

I am getting a segmentation fault on the command:
FILE *Afp;
in a seldom used program from a couple of years back. Commenting it out "seems" to solve it i.e. no error message.
Program uses: if ((Afp = fopen("./DTAdir/Abufer1", "w")) == NULL) {
Have I been living in a cave too long? Has FILE been deprecated?
Any thoughts as to why the segmentation fault is occurring welcomed.

[i92guboj]

I am getting a segmentation fault on the command:
FILE *Afp;
in a seldom used program from a couple of years back. Commenting it out "seems" to solve it i.e. no error message.
Program uses: if ((Afp = fopen("./DTAdir/Abufer1", "w")) == NULL) {
Have I been living in a cave too long? Has FILE been deprecated?
Any thoughts as to why the segmentation fault is occurring welcomed.

If you are talking about the C FILE data type, then I can't think of absolutely no reason why defining a variable of the type FILE will make your program segfault. The problem is elsewhere on your code. Probably, when accesing to unallocated or incorrectly allocated memory via pointers or something.

The C syntax doesn't deprecate, because it's based on a Standard. It will be the same for the next 10,000 years or so :P What amazes me, is that your program compile when you comment that line. It shouldn't, since you are using a variable that has not been declared.

[clickit]

Regarding commenting the line, your response is basically mine.
Don't think seg fault is elsewhere since I bracketed the line with printouts and get the seg fault and no output from the subsequent line.
These are the reasons I thought there may have been changes.
This is one for the books.

[i92guboj]

Regarding commenting the line, your response is basically mine.
Don't think seg fault is elsewhere since I bracketed the line with printouts and get the seg fault and no output from the subsequent line.

Remember that the order in which the code is run it not necessarily the same that you can semantically think of when you read the C code. Also, it can (and is) influenced by some compiler flags and the architecture.

Nothing has changed in the C standard, and I think that the problem is elsewhere, not in the declaration. But if you are really really sure about what you say, then maybe the problem is a defective compiler, the use of weird CFLAGS or the use of an unstable version of gcc.

These are the reasons I thought there may have been changes.
This is one for the books.

Standards don't change, by definition. C will always be C. If you change the basics of the language, then you don't have C, it would be called anything else.

If we could take a look at the code we could try to spot the problem.

[scm]

I agree with what's already been said, so I'd apply the first rule of debugging: "if you can't see the problem where you're looking, you're looking in the wrong place."

IME, commenting out variables often "cures" a SEGV since it shifts the allocated memory around so it might just start apparently working. I've also found that sprinkling printf's around faulty code also "fixes" SEGV's so you're lucky if yours still faults at the same place. Post the code - we like a challenge!

[clickit]

Thanks all. I am aware of what was proffered but had forgotten the difference between fopen and open and that difference in relation to the file descriptor. That resolved the "apparent" problem with FILE.
Again thanks.