Help - opening a file with a char pointer as the name

[Theoren]

Hello, I just started programming at C, and I'm trying to make a program that receives a string of unknown length and opens a file with that name, the code apparently receives the string with no problem (when I print the name, it appears correctly), but when I try to open the file it just doesn't work...

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

main() {
   char *nome = NULL;
   char temp = '\0';
   int tamanho = 0;
   
   printf("Type the file name: ");
   
   while (temp != '\n') {
      scanf("%c", &temp);
      tamanho++;
      if ((nome = (char *) realloc (nome, tamanho)) == NULL) {
         printf("Allocation error\n");
         system("pause");
         exit(1);
      }
      
      nome[tamanho] = '\0';
      nome[tamanho - 1] = temp;
   }
   
   FILE *arq;
   if ((arq = fopen (nome, "w")) == NULL) {
      system("pause");
      exit(1);
   }
   
   system("pause");   
}

Thanks in advance.

[tabstop]

If you have realloc'ed tamanho bytes, then nome[tamanho] does not exist, despite your attempts to write to it.

Does the fopen fail? Or does the file you create not have the name you expect?

[Elysia]

Me thinks your system is overcomplicated.
Define a large enough buffer for the filename and use fgets.
And main returns int.

[Theoren]

tabstop: the fopen fails.

[tabstop]

I did the test of your code, and the nome filename does contain a new line character. Why? Because you add the temp character to the filename before you get back to the top of the loop and check whether or not it's \n.

But I agree: a buffer is the best solution for this problem.

[Theoren]

I modified the program to test if the char is a newline before adding it to the name and it seems to be working. But can you please explain me this better solution of using a buffer and fgets? As I said, I'm just starting, so I don't know how to do it.

[Elysia]

char buf[100];
fgets(buf, sizeof(buf), cin);
FILE* f = fopen(buf, "w");
/* bla bla bla */

But fgets reads the newline, so you may want to strip it.

[graydot]

Theoren, you code actually works perfectly fine on my gcc compiler. I can find the file test created. I am using Netbeans on Ubuntu Hardy Heron.

[zacs7]

I'd say you're unlucky then graydot

Perhaps the best way to demonstrate the over-run is as such:

char arr[0];                 /* not legal, but this is for demo purposes :) */
size_t count = 0;
char tmp;

scanf("%c", &tmp);
count = 1;
resize arr to count bytes... That is arr now has size 1.

/* at this point arr has size of 1 element */

arr[count] = '\0';          WRONG count = 1, which is out of bounds in this case. You should get a segfault.
arr[count - 1] = tmp;       Right, it's in bounds. But legally there should be no nul-terminator after it.

... and the loop of errors repeats

And the reason it didn't SegFault is probably because the realloc() gave you more bytes than you asked for (possibly to be on a word boundary). Consider yourself unlucky too Theoren.

[graydot]

hey. thanks a lot. that is more understandable. I didn't know realloc did that.

[graydot]

and yes, it should segfault.

[Elysia]

It has nothing to do with realloc, and everything to do with arrays in C.
When you allocate n elements of an array, you can access those elements through the range 0...n-1. There exists no element "n".

[graydot]

i got that part. actually later. but what i was saying that usually i get a error when i try to access an element of the array that does not exist that way. so i didn't go into the logic too much. i assumed if accessing was not giving an error there was no logic error in that.
since realloc may assign extra space, it wasn't segfaulting.

[Elysia]

Unfortunately, not only realloc has this behavior. Malloc does too and if you're doing on the stack, the consequences can be even worse, since the stack is long, you probably have a bunch of room to overwrite.
When doing C, you must be very careful. It's not a friendly language.

[matsp]

Besides from writing outside the array, I believe the last character in the filename is '\n', which may not be a valid filename, so opening that would not work.

--
Mats