FILE * f = fopen("/documents/miner/mapdata.tns", "r");
for(j = 0; j < 10120; j++)
   fscanf(f, "%d", &map[j]);
fclose(f);

How do I put in scanf?
Compiler doesn't recognize it

I don't see any -nostdlib in my makefile.

You mean something like this?

FILE *f = fopen("/documents/miner/mapdata.tns", "w+");
fwrite(map, sizeof(int), 32000, f); //32000 blocks in map
fclose(f);

FILE *f = fopen("/documents/miner/mapdata.tns", "r");
fread(map, sizeof(int), 32000, f);
fclose(f);

Yup, that works

It works for all numbers, even something like
fwrite(map, 1, 3, f) with 24 bit integers
24000 * 1 byte(char) = 6000 * 4 byte(int)
fwrite and fread don't care about what they're writing/reading, you only have to give the size of your object.

You're freeing a memory location which was not allocated with malloc... which does, usually, precisely trigger a crash

Plop,

I've been encountering some problems with Ndless' UI features. This code :

Code: [Select]

show_msgbox_2b("Title", "Text", "Button 1", "Button 2");Gives that :



And it's basically the same with show_msgbox_3b (displays a dialog box with 3 buttons) ; the labels are "Button 1Button 2Button 3", "Button 2Button 3" and "Button 3".

Not sure why, but in _show_msgbox.c, I found this
char button1_16[14];
char button2_16[14];
This explains your problem. Do not make your button text longer than 7 characters (without the \0).

If you have a text larger than 7 characters and don't want to wait ExtendeD to change the trunk, you can change it to
char button1_16[(strlen(button1) + 1) * 2];
char button2_16[(strlen(button2) + 1) * 2];

And later, change
char button3_16[14];

to

char button3_16[(strlen(button3) + 1) * 2];

And recompile libndls.a (Ndless).

Also, this code just crashes nspire_emu :

Code: [Select]

char filename[256];
show_msg_user_input("Test", "Test this", "Default", &filename);
printf("%s", filename);
free(filename);

return 0;
I think that it's a bug with Ndless ...

1) free() on a char filename[256] does crash, even in a computer program. filename[256] is a static allocation contrary to malloc.
2) filename[256] : you surely don't need this, look at the example in ndless/libndls/show_msg_user_input.c
You have to pass a pointer to your char array, but you should not initialize it ! Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.
3) Do not free if the popup returned -1, because the popup was canceled, there is no result, and your char array is not initialized. Again, checkout the sample code in ndless/libndls/show_msg_user_input.c

Indeed, you don't know its size and putting arbitrary size (here 256) is a bad programming behavior.

I don't want to be a nitpicker, but I have to disagree. In a practical context, using "big enough" buffers when dealing with arbitrary-sized strings is in many cases better than hassling around with a bunch of pointers and dynamically allocated memory. Using the latter method complexifies and bloats the code unnecessarily, gives the programmer additional responsibility (gotta compute the size of the data, malloc it, remember to free the memory, etc.), decreases the programs maintainability (as the code for that filename container is scattered around, when modifying bigger chunks better check it doesn't cause any undefined behavior), and generally the whatever academic perfection of the code doesn't outweigh the pain of dealing with such trivial stuff. We're not talking about security-critical government-class programs here, and it's not like there aren't any functions to avoid buffer overflows and whatnot.
I'm not saying you should be using statically allocated data for everything (quite the contrary usually), but for string buffers and such, a char buf[BUF_SIZE]; is usually good enough.