Hello to you all ,

Major problem in C , Files included

Summary of problem :
Program will not copy the feild "name" from struct "univ->std.name" properly. the rest of data is presented fairly.
do not touch function "output_university" .

Thank you ,

yotam , Israel .

Dani AI

Generated

In this thread reports that the name field isn’t being preserved and that adding a copy call fixed one item but then broke another. As observed, the missing copy is only the most obvious symptom. When adding the copy causes other strings to corrupt the real root cause is almost always a boundary or allocation error — common cases are (a) allocating the wrong number of bytes (forgetting the terminating NUL), (b) reading into a temporary buffer without a width limit, or (c) losing/overwriting pointers because realloc or pointer initialization is mishandled (the latter was noted by ).

Safer allocation/copy pattern (check sizes and failures): always allocate strlen(buffer) + 1, check the malloc return, and copy the bytes including the terminating NUL. strdup is convenient where available, but explicit allocation lets the program react to OOM:

size_t len = strlen(buffer);
char *name = malloc(len + 1);
if (!name) { /* handle OOM */ }
memcpy(name, buffer, len + 1);
univ->std[num_cells].name = name;

Realloc and pointer-safety: never assign the result of realloc directly back into the original pointer without checking. Use a temporary pointer and preserve the original on failure. Also avoid casting the result of malloc/realloc in C and include <stdlib.h> so prototypes are visible:

void *tmp = realloc(univ, new_bytes);
if (!tmp) { /* handle OOM; keep original univ intact */ }
univ = tmp;

Practical debugging and hardening: compile with -Wall -Wextra -g and use AddressSanitizer (-fsanitize=address) or Valgrind to catch overruns and use-after-free. Prefer fgets plus parsing (or width-limited scanning) for input, print pointer addresses and strlen() values after allocation, and free temporary buffers appropriately. Those checks will usually reveal the off-by-one, overflow, or realloc mistake that produces the cascading corruption seen here.

Recommended Answers

All 4 Replies

In function input_university() I see where scanf() is reading the string, and univ->std[num_cells].name is getting allocated, but I don't see where it is copying buffer to univ->std[num_cells].name after allocation. Add this and it will probably work ok.

strcpy(univ->std[num_cells].name,buffer);

Apparently, I wasted my time :mad:
http://www.daniweb.com/techtalkforums/thread43435.html

Not only have you dropped the initialisation of univ in main(), but you've gone back to using fscanf to read the file.
Not only that, you're now using global variables like "temp", which get allocated on every iteration of the loop and never freed.
Don't forget the not using a temporary variable when calling realloc, nor the unnecessary casting of malloc and realloc.

Y'know what, if you're just going to ignore people, just say so - ok?

Apparently, I wasted my time :mad:
http://www.daniweb.com/techtalkforums/thread43435.html

Not only have you dropped the initialisation of univ in main(), but you've gone back to using fscanf to read the file.
Not only that, you're now using global variables like "temp", which get allocated on every iteration of the loop and never freed.
Don't forget the not using a temporary variable when calling realloc, nor the unnecessary casting of malloc and realloc.

Y'know what, if you're just going to ignore people, just say so - ok?

I guess i didnt see it - sorry mate :confused:

In function input_university() I see where scanf() is reading the string, and univ->std[num_cells].name is getting allocated, but I don't see where it is copying buffer to univ->std[num_cells].name after allocation. Add this and it will probably work ok.

strcpy(univ->std[num_cells].name,buffer);

I did just that . now it messes up another string - i'll figure it out
somehow , the thing is , we were never tought the subject BUFSIZ and
"sscanf" - so no offence there ;)
i got slapped on using it .... sorry

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.