Yeah, what else is in your code?
That, by itself, isn't a problem (except for the leak at the end)
Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main ( ) {
char record[100];
int N=0;
typedef struct{
double x,y;
int year;
}eggrafi;
eggrafi *arxeio=NULL,*arxeio1;
while(N<15)
{
arxeio1=(eggrafi*)realloc(arxeio,(N+1)*sizeof(eggrafi));
arxeio=arxeio1;
arxeio[N].x=596.369;
arxeio[N].y=596.639;
arxeio[N].year=5;
N++;
}
return 0;
}
$ ./a.out
$ valgrind a.out
valgrind: a.out: command not found
$ valgrind ./a.out
==2017== Memcheck, a memory error detector
==2017== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2017== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==2017== Command: ./a.out
==2017==
==2017==
==2017== HEAP SUMMARY:
==2017== in use at exit: 300 bytes in 1 blocks
==2017== total heap usage: 15 allocs, 14 frees, 2,400 bytes allocated
==2017==
==2017== LEAK SUMMARY:
==2017== definitely lost: 300 bytes in 1 blocks
==2017== indirectly lost: 0 bytes in 0 blocks
==2017== possibly lost: 0 bytes in 0 blocks
==2017== still reachable: 0 bytes in 0 blocks
==2017== suppressed: 0 bytes in 0 blocks
==2017== Rerun with --leak-check=full to see details of leaked memory
==2017==
==2017== For counts of detected and suppressed errors, rerun with: -v
==2017== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 8)
If you screw up with malloc at any point in the program, then the effect can show up
- immediately,
- some time later, in an unrelated part of the program
- far in the future, like a change of OS or compiler
- never
It looks like door number 2 to me.