---

Hej

Jeg skal lave en lille ting i C, men gider egentlig ikke lære at programmere i
C, da jeg er så god (som jeg gider være) til Fortran. Desværre er der ingen
vej udenom at lave dette i C, da jeg har fået en større omgang i C, som jeg
skal tilføje lidt mere til.

Men jeg mangler en funktion, der kan læse en fil ind til et array. Ligger en
eller anden inde med en sådan, så jeg slipper for at læse endnu flere
tutorials? Jeg har ti datafiler af forskellig størrelse, så det ville være
smartest, hvis funktionen selv kunne gennemskue, hvor mange tal, der er pr.
linie, og hvor mange linier der er pr fil. Men hvis nogen ligger inde med en
funktion, der bare læser en fil af given størrelse ind, må jeg vel finde ud af
resten selv.

Jeg synes, det virker ret bøvlet - er det bare mig? Hvorfor skal det fylde
mere, end de fem linier, det ville fylde i F90?

-Christian Vinter
--
Christian Vinter
Student of astrophysics.
University of Copenhagen, Denmark
http://www.fys.ku.dk/~vinter

---

Christian Vinter wrote:

> Men jeg mangler en funktion, der kan læse en fil ind til et array.
> Ligger en eller anden inde med en sådan, så jeg slipper for at læse
> endnu flere tutorials? Jeg har ti datafiler af forskellig størrelse, så
> det ville være smartest, hvis funktionen selv kunne gennemskue, hvor
> mange tal, der er pr. linie, og hvor mange linier der er pr fil. Men
> hvis nogen ligger inde med en funktion, der bare læser en fil af given
> størrelse ind, må jeg vel finde ud af resten selv.

Noget i denne stil måske:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

struct _FileContent
{
size_t size;
char * data;
};

typedef struct _FileContent FileContent;

FileContent readFileContent(char * filePath)
{
struct stat st;
FileContent content = {0,NULL};
FILE * file;

if(stat(filePath, &st) == 0 && (file = fopen(filePath,"r")) !=
NULL)
{
content.size = st.st_size;
content.data = (char*)malloc(st.st_size);
fread(content.data, 1, st.st_size, file);
fclose(file);
}

return content;
}


Jeg har hverken compilet eller testet det, men jeg kan ikke se noget
galt med den. Hvis noget gik galt undervejs (f.eks. filen eksisterer
ikke) er content.data = NULL. Når du er færdig med at bruge dataene skal
de deallokeres med:

free(content.data);

Det er godt nok ikke særlig optimalt at indlæse en hel fil på én gang.
Sådan én kan jo være stor, så du skulle måske kigge på fgets()
funktionen, som indlæser en linje af gangen.

Robert

---

[ Robert Larsen ]

[ ... ]

> Noget i denne stil måske:


Kanskje ikke.

[ ... ]


> struct _FileContent


Navn (eng: identifiers) som begynner med "_" etterfulgt av en "_"
eller en stor bokstav er reservert for implementasjonen i alle
kontekster. Fx. C99, 7.1.3 p 1. Hvilken funksjon har "_" i dette
navnet? Det _er_ lov å si:

typedef struct foo foo;

.... dersom man ikke liker 'struct'ene.


> {
> size_t size;
> char * data;
> };


Nei. Filstørrelser på de platformene hvor man har stat, måles i off_t
(fx. SUSv3 og POSIX (ISO/IEC 9945-1: 1996)).

[ ... ]


> if(stat(filePath, &st) == 0 && (file = fopen(filePath,"r")) != NULL)
> {
> content.size = st.st_size;
> content.data = (char*)malloc(st.st_size);


Og nå til dagens spørsmål -- _hva_ var vitsen med å stat'e igjen? For
å få filstørrelsen? For at det vil nemlig ikke virke, avhengig av
_hva_ filen inneholder og hva _filen_ egentlig er.


> fread(content.data, 1, st.st_size, file);


Du ser også ut til å anta at filen inneholder den _eksakte_ binære
representasjonen av en array. Hvorfor det?

[ ... ]


> Jeg har hverken compilet eller testet det, men jeg kan ikke se noget
> galt med den.


Hvorfor var det igjen du gadd å poste et dårlig forslag til en enda
dårligere spesifisert problemstilling?





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

Igor V. Rafienko wrote:

> Og nå til dagens spørsmål -- _hva_ var vitsen med å stat'e igjen? For
> å få filstørrelsen? For at det vil nemlig ikke virke, avhengig av
> _hva_ filen inneholder og hva _filen_ egentlig er.

Han bad om at få alt indlæst på én gang. Så er man nødt til at kende fil
størrelsen. Fair nok at jeg skulle have læst dem binært. So sue me.

> Du ser også ut til å anta at filen inneholder den _eksakte_ binære
> representasjonen av en array. Hvorfor det?

Igen....ja. Jeg burde have læst filen binært, og det gør jeg normalt
også altid.

> Hvorfor var det igjen du gadd å poste et dårlig forslag til en enda
> dårligere spesifisert problemstilling?

Fordi så havde gutten noget at arbejde med. Hvad har du bidraget med ??

---

Robert Larsen wrote:

> Fordi så havde gutten noget at arbejde med. Hvad har du bidraget med ??

At få problemet specificeret mere præcist. Og dermed øget chancerne
for, at Christian får noget hjælp væsentligt.

Jeg ser Igors indlæg som yderst hjælpsomt.

--
Jens Axel Søgaard

---

Jens Axel Søgaard wrote:

> Jeg ser Igors indlæg som yderst hjælpsomt.

Den engelske udgave af
<http://www.catb.org/~esr/faqs/smart-questions.html>
er ret god.

--
Jens Axel Søgaard

---

[ Robert Larsen ]

[ ... ]

> Han bad om at få alt indlæst på én gang. Så er man nødt til at kende
> fil størrelsen. Fair nok at jeg skulle have læst dem binært. So sue
> me.


Det var ikke det innvendingen min gikk ut på. Som jeg sa (og som jeg
sier _igjen_), det å stat'e filen vil _ikke_ virke for visse verdier
av "fil" og "filens innhold". Vil du ha et par eksempler konstruert
til formålet?

Det er faktisk ingen annen måte å kjenne filens størrelse på enn å
lese hele filen. Iallfall for visse definisjoner av "størrelse".
_Derfor_ er det meget _viktig_ å få vite _hva_ filen inneholder,
_hvordan_ dette er strukturert og _hvor_ dataene kommer i fra. stat()
er temmelig verdiløs for slike "abstrakt spesifiserte" oppgaver.

[ ... ]


> Fordi så havde gutten noget at arbejde med. Hvad har du bidraget med
> ??


Foreløpig har det ikke vært så veldig mye å bidra _til_. Ser du den
lille forskjellen?





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

[ Christian Vinter ]

[ ... ]

> Jeg skal lave en lille ting i C, men gider egentlig ikke lære at
> programmere i C, da jeg er så god (som jeg gider være) til Fortran.
> Desværre er der ingen vej udenom at lave dette i C, da jeg har fået
> en større omgang i C, som jeg skal tilføje lidt mere til.


Kjære venner, det viser seg at jeg må fly helikopter fra A til B. Jeg
gidder egentlig ikke å lære å fly helikopter, da jeg er Schumacher bak
rattet på min Lada, men i dette tilfellet er det ingen vei utenom å
fly. Jeg gidder heller ikke å fortelle hvor A og B er hen, men kunne
ikke noen fortelle meg alt jeg trenger for å komme fra A til B? Og
aller helst en "step-by-step" veiledning slik at jeg slipper å tenke i
det hele tatt (passer veldig bra til en Futuramaepisode sendt på
svensk TV4 for et par dager tilbake).


> Men jeg mangler en funktion, der kan læse en fil ind til et array.
> Ligger en eller anden inde med en sådan, så jeg slipper for at læse
> endnu flere tutorials?


Hva men å kjøpe _en eneste bok_ som holder til formålet og bruke
bittelitt tid på det? ISBN 0131103628, fx.


> Jeg har ti datafiler af forskellig størrelse, så det ville være
> smartest, hvis funktionen selv kunne gennemskue, hvor mange tal, der
> er pr. linie, og hvor mange linier der er pr fil.


Det er _trivielt_ å skrive noe slikt selv for en nybegynner, men du
ser ut til å ha utelatt mye av ganske vesentlig informasjon:

* formatet på filen. Fx. hva er en linje?
* formatet på tallene. Fx. hva er ett tall?
* felt separatorer. Hvordan er tallene adskilt?
* kilden til datafilen. Kan data være korrupte? Er det mye
feilhåndtering som man trenger å bry seg om? Hva er størrelsesorden
til datafilen (1MB eller 1GB?)
* enkodingen på dataene. ASCII, binært, en eller annen hjemmelaget
representasjon?


> Men hvis nogen ligger inde med en funktion, der bare læser en fil af
> given størrelse ind, må jeg vel finde ud af resten selv.


Dersom du tar en titt på fseek, ftell og fread, så har du alle de
nødvendige elementene for å lese fra en fil. Men jeg anbefaler å
reflektere litt over spørsmålne stilt over.


> Jeg synes, det virker ret bøvlet - er det bare mig? Hvorfor skal det
> fylde mere, end de fem linier, det ville fylde i F90?


Nå ble antall linjer et mål på noe annet enn hvor mye vedkommende
misforstår problemet som skal løses?

Oppgaven _er_ enkel, dersom oppgaven er velspesifisert. Du kunne
kanskje prøve på det _først_ for _så_ å gå over til å løse oppgaven i
C?

*shrug*





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

Så sku' da også! Jeg prøvede med alle høflighedsfraser og indrømmelser, og så:

Igor V. Rafienko wrote:

> Kjære venner, det viser seg at jeg må fly helikopter fra A til B.

Spar mig for dine billeder. Jeg skal programmere - ikke flyve.

> Hva men å kjøpe _en eneste bok_ som holder til formålet og bruke
> bittelitt tid på det? ISBN 0131103628, fx.

Jeg håber ikke, jeg lagde skjul på, jeg er doven og *totalt* newbie udi C,
samt at jeg håbede, at kunne slippe om ved dette på en nem måde. Det var
derfor, jeg spurgte, om nogen havde noget fikst og færdigt. Og det var derfor,
jeg sagde, at hvis det ikke var tilfældet, skulle jeg nok selv finde ud af det.

Jeg fatter ikke, du gider fare op på denne måde. Men skulle du have lyst til
at hjælpe, eller endnu bedre: Har du den efterlyste funktion, vil hjælp være
meget velkomment.

> Det er _trivielt_ å skrive noe slikt selv for en nybegynner,

Well, så er du klogere end mig. Tillyke med det.

> men du
> ser ut til å ha utelatt mye av ganske vesentlig informasjon:

[SNIP]

Jeg svarer på dette til Per, der efterlyser det samme - han virker som om han
hellere vil hjælpe end bruge usenet til at styrke sit ego.

> *shrug*

....at du gider...

-vinter

--
Christian Vinter
Student of astrophysics.
University of Copenhagen, Denmark
http://www.fys.ku.dk/~vinter

---

[ Christian Vinter ]

> Så sku' da også! Jeg prøvede med alle høflighedsfraser og
> indrømmelser,


La oss se, du sier noe i retning av "jeg gidder ikke å lære, men fiks
dette for meg den som vil" og _det_ kaller du høflig? Hvor _er_ du
blitt oppdratt?

[ ... ]


> > Kjære venner, det viser seg at jeg må fly helikopter fra A til B.
>
> Spar mig for dine billeder. Jeg skal programmere - ikke flyve.


Men du forstod kanskje ikke hva jeg siktet til? Det er greit, la oss
prøve dette en gang til.

Enhver oppgave er relativt enkel, så snart man har forstått
problemstillingen (denne delen er språkuavhengig, så man skulle jo med
rimelighet anta at en F90 programmerer ville ha taklet det. Den gang
ej). En del av av å forstå problemstillingen er å forstå input til
programmet. ACM sin programmeringskonkurranse er veldig eksplisitt på
akkurat dette punktet. Du har ikke gitt en eneste indikasjon i den
opprinnelige meldingen på hva programmet skulle få av input, og dermed
er det uinteressant å begynne å _gjette_ på hva som _skulle_ være
løsningen (selv om, til min stor forargelse, var det en rekke personer
som forsøkte på nettopp det).

For å få datamaskinen til å løse et problem for deg (uansett
realisasjonsspråket), må man i det minste forstå problemet selv,
akkurat som for å kunne fly kreves det visse kunnskaper om navigasjon,
kart, o.l. Hjalp sammenligningen denne gangen?


> > Hva men å kjøpe _en eneste bok_ som holder til formålet og bruke
> > bittelitt tid på det? ISBN 0131103628, fx.
>
> Jeg håber ikke, jeg lagde skjul på, jeg er doven og *totalt* newbie
> udi C,


.... hvilket resulterte i at jeg anbefalte _nettopp_ denne boken. Har
du _sett_ i innholdsfortegnelsen? Eller kanskje tatt deg bryet til å
gå på biblioteket og ta deg tid til å titte litt på selve boken? Det
er nemlig en viss mulighet for at selv et så lærebakstreversk individ
som deg kan faktisk hente noe ut av denne boken.


> samt at jeg håbede, at kunne slippe om ved dette på en nem måde. Det
> var derfor, jeg spurgte, om nogen havde noget fikst og færdigt.


Helt utrolig. Du _insisterer_ på å _forbli_ ignorant.

[ ... ]


> Jeg fatter ikke, du gider fare op på denne måde.


Det kan jeg godt forstå. Men svar meg på en ting, fatter du _hva_ jeg
_svarte på_ og _hvorfor_ jeg gjorde det?


> Men skulle du have lyst til at hjælpe, eller endnu bedre: Har du den
> efterlyste funktion, vil hjælp være meget velkomment.


Ja, jeg har lyst til å hjelpe, men kun dem som har lyst til å lære.
Med mindre du utviser et snev av læreviljen, får du ingenting servert
ferdig av _meg_ (ikke at det trenger å bety så veldig mye, når det
finnes folk som ser ut til å være fryktelig fornøyde med å poste
"løsninger" som virker stort sett men ikke helt og det for en passende
definisjon av problemet ditt. Litt synd at _de_ gidder, men det er
svært lite _jeg_ kan gjøre for å rette på saken).

Dog, du har allerede lært en ting -- viktigheten av å spesifisere
problemstillingen. Sånn sett er jeg fornøyd med bidraget mitt.


> > Det er _trivielt_ å skrive noe slikt selv for en nybegynner,
>
> Well, så er du klogere end mig. Tillyke med det.


Igjen, du går glipp av poenget.

Sett deg ned med papir og blyant, tenk over spørsmålene som jeg
stilte, noter svarende på disse. Noter så hvilke _høynivå_ skritt
programmet ditt må foreta for å lese filen. _Så_ kan du begynne å bry
deg om hvordan du skal realisere disse skrittene i C, utifra
mulighetene som C tilbyr. Litt mer presist kan du titte i kapittel 5
(pekere og arrays) og 7 (I/O og storage management) i den overnevnte
boken, kladde litt og komme tilbake med et forslag som du mener burde
holde.

Når du har gjort det, _da_ har du gjort deg fortjent til å spørre om
råd til programmet. Og _det_ vil være høflig opptreden på njus. Man
skal ikke se bort i fra at der du kommer ifra er det vanlig å velge en
annen framgangsmåte, men slik er altså ikke ting på Usenet.

[ ... ]


> Jeg svarer på dette til Per, der efterlyser det samme - han virker
> som om han hellere vil hjælpe end bruge usenet til at styrke sit
> ego.


Godt, da du lærer i det minste _noe_.





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

Igor V. Rafienko wrote:

>
> La oss se, du sier noe i retning av "jeg gidder ikke å lære,

....og heller ikke læse dine bitre opstød", så dækker det noget meget godt.

-vinter

---

[ Christian Vinter ]

[ ... ]

> > La oss se, du sier noe i retning av "jeg gidder ikke å lære,
>
> ...og heller ikke læse dine bitre opstød", så dækker det noget meget
> godt.


Vel, da har du nok ikke forstått hva jeg ville fram til. Det er synd
siden du unngikk å lære noe.





ivr
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---

Christian Vinter <vinter@SLET.fys.ku.dk> writes:

> Men jeg mangler en funktion, der kan læse en fil ind til et
> array. Ligger en eller anden inde med en sådan, så jeg slipper for at
> læse endnu flere tutorials?

Måske hvis du er heldig, og har en præcis definition af hvilket format
filen er i, og hvilket format den resulterende datastruktur skal have.

> Jeg synes, det virker ret bøvlet - er det bare mig? Hvorfor skal det
> fylde mere, end de fem linier, det ville fylde i F90?

Fordi C er et primitivt, men fleksibelt sprog. Hvis du er villig til
at skrive i C++ kan mange formater læses ind med ganske få linier
kode.

---

Per Abrahamsen wrote:

>
> Måske hvis du er heldig, og har en præcis definition af hvilket format
> filen er i, og hvilket format den resulterende datastruktur skal have.

Well, det er 100 - 300 liner ASCII med 4 - 16 søjler af reelle tal. Ikke noget
stort. Tallene er adskildt af mellemrum. Kunne se således ud:

1052.00191 17.987 0.018 1.668 2927.000 11 14.574 0.008 14.464 0.008 14.817
1052.01238 17.488 0.141 1.563 2799.000 11 14.236 0.230 14.212 0.124 14.303
1052.02187 17.993 0.016 1.792 2812.000 11 14.576 0.006 14.466 0.006 14.815
1052.04166 18.005 0.017 1.764 2882.000 11 14.570 0.008 14.466 0.008 14.816

Det skal bare læses ind i et array som en pokkers masse floats (og evt den ene
søjle med integers. Men det er ligemeget, om de læses ind som floats).

>>Jeg synes, det virker ret bøvlet - er det bare mig? Hvorfor skal det
>>fylde mere, end de fem linier, det ville fylde i F90?
>
>
> Fordi C er et primitivt, men fleksibelt sprog. Hvis du er villig til
> at skrive i C++ kan mange formater læses ind med ganske få linier
> kode.

WOW. Jeg tror, vi har slået fast, jeg er doven. C++ (har jeg fundet ud af) ser
ret vildt ud. Een ting ad gangen

Det ville være fedt, hvis du havde noget. Ellers har jeg faktisk været på
biblioteket på foranledning af den gode Igor, men Pixi synes ikke at have
udgivet bøger om C-programmering, så jeg måtte låne nogen større bøger.

På forhånd tak:

-vinter
--
Christian Vinter
Student of astrophysics.
University of Copenhagen, Denmark
http://www.fys.ku.dk/~vinter

---

"Christian Vinter" <vinter@SLET.fys.ku.dk> wrote

[8<8<8<]
> 1052.00191 17.987 0.018 1.668 2927.000 11 14.574 0.008 14.464 0.008
14.817
> 1052.01238 17.488 0.141 1.563 2799.000 11 14.236 0.230 14.212 0.124
14.303
> 1052.02187 17.993 0.016 1.792 2812.000 11 14.576 0.006 14.466 0.006
14.815
> 1052.04166 18.005 0.017 1.764 2882.000 11 14.570 0.008 14.466 0.008
14.816
>
> Det skal bare læses ind i et array som en pokkers masse floats (og evt den
ene
> søjle med integers. Men det er ligemeget, om de læses ind som floats).

Skal tal fra samme linie holdes sammen, eller er linierne uden betydning ?


[8<8<8<]
> WOW. Jeg tror, vi har slået fast, jeg er doven. C++ (har jeg fundet ud af)
ser
> ret vildt ud. Een ting ad gangen

Hvis du er doven, så bruger du C++ i stedet for C.
Her er et bud på både hvor alle tallene læses ind i eet array (vector), og
hvordan læses ind i et array af arrays hvor hver linie holdes for sig:
<C++ kode>
#include <fstream>
#include <sstream>
#include <iostream>
#include <vector>
#include <string>
#include <iterator>

using namespace std;

void real_double_array(const char* data_file_name)
{
ifstream is(data_file_name);
if(!is) {
cerr << "Unable to open file: " << data_file_name;
return;
}

vector<double> values;
copy(istream_iterator<double, char>(is), istream_iterator<double,
char>(),
back_inserter(values));
}

void real_line_double_array(const char* data_file_name)
{
ifstream is(data_file_name);
if(!is) {
cerr << "Unable to open file: " << data_file_name;
return;
}

vector<vector<double> > values;
string line_text;
while(getline(is, line_text)) {
istringstream isl(line_text);
vector<double> line_values;
copy(istream_iterator<double, char>(isl), istream_iterator<double,
char>(),
back_inserter(line_values));
values.push_back(line_values);
}
}

int main(int argc, char* argv[])
{
for(int argi = 1; argi < argc; ++argi) {
real_double_array(argv[argi]);
real_line_double_array(argv[argi]);
}
}
</C++ kode>

Venlig hilsen

Mogens Hansen

---

Mogens Hansen wrote:

> "Christian Vinter" <vinter@SLET.fys.ku.dk> wrote
>
> [8<8<8<]
>
>> 1052.00191 17.987 0.018 1.668 2927.000 11 14.574 0.008 14.464 0.008
>
> 14.817
>
>> 1052.01238 17.488 0.141 1.563 2799.000 11 14.236 0.230 14.212 0.124
>
> 14.303
>
>> 1052.02187 17.993 0.016 1.792 2812.000 11 14.576 0.006 14.466 0.006
>
> 14.815
>
>> 1052.04166 18.005 0.017 1.764 2882.000 11 14.570 0.008 14.466 0.008
>
> 14.816
>
>>Det skal bare læses ind i et array som en pokkers masse floats (og evt den
>
> ene
>
>>søjle med integers. Men det er ligemeget, om de læses ind som floats).
>
>
> Skal tal fra samme linie holdes sammen, eller er linierne uden betydning ?
>
>
> [8<8<8<]
>
>>WOW. Jeg tror, vi har slået fast, jeg er doven. C++ (har jeg fundet ud af)
>
> ser
>
>>ret vildt ud. Een ting ad gangen
>
>
> Hvis du er doven, så bruger du C++ i stedet for C.
> Her er et bud på både hvor alle tallene læses ind i eet array (vector), og
> hvordan læses ind i et array af arrays hvor hver linie holdes for sig:
>

[SNIP C++ kode]

Hvis du er doven og ikke gider sætte dig ind i C++'s vectorer kan man
lave det i C:

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

double *array;
int array_size;

int main(int argc, char *args[])
{
FILE *f;
char *s, line[1024];
int malloc_count = 0, i;

if(argc != 2)
{
fprintf(stderr, "You have to specify a file to read\n");
return EXIT_FAILURE;
}
if((f = fopen(args[1], "rt")) == NULL)
{
fprintf(stderr, "I can't open %s for reading\n", args[1]);
return EXIT_FAILURE;
}
while(fgets(line, sizeof(line), f))
{
s = strtok(line, " \n");
while(s)
{
if(array_size >= malloc_count)
{
malloc_count += 32;
if((array = realloc(array,malloc_count*sizeof(*array))) == NULL)
{
fprintf(stderr, "I'm out of memory!\n");
return EXIT_FAILURE;
}
}
array[array_size++] = strtod(s, NULL);
s = strtok(NULL, " \n");
}
}
for(i = 0; i < array_size; i++)
printf("%f\n", array[i]);

free(array);

return 0;
}

/b

---

Tak til alle, der forsøgte at hjælpe.
Der var ikke nogen, der havde præcis det, jeg manglede, men med inspiration
herfra, fik jeg selv klaret det.

-vinter

---

> Men jeg mangler en funktion, der kan læse en fil ind til et array. Ligger
en
> eller anden inde med en sådan, så jeg slipper for at læse endnu flere
> tutorials?

#include "stdlib.h"
#include "stdio.h"

bool ReadFile2Array ( char *filename, char* &outbuffer )
{
FILE *file = fopen ( filename, "rb" );
long filesize;

if (file == NULL)
return false;

fseek ( file, 0L, SEEK_END );
filesize = ftell ( file );
fseek ( file, 0L, SEEK_SET );

outbuffer = (char*) malloc (filesize);
fread ( outbuffer, 1, filesize, file );
fclose ( file );

return true;
};