Author Topic: [68k] Storing a value into n? (Read 12207 times)

blue_bear_94 · « **Reply #15 on:** June 06, 2012, 10:53:53 am »

Oh, I get ARB_INT_TAG now. It's like when you solve sin(x)=0, the solution is x=pi*@n1. Basically they're numbers into which anything can be stored and the solution is still true?
So I was using fopen and returning a list representing the FILE structure:

Code: [Select]

case 24:
		a=GetArgType(argptr);
		if (a!=STR_TAG)
		{
			DlgError("Arg 2 must be string");
			return;
		}
		const char* f3=GetStrnArg(argptr);
		fio=fopen(f3,"r+b");
		push_END_TAG();
		push_longint((long)fio->fpos);
		push_longint((long)fio->base);
		push_longint(fio->handle);
		push_longint(fio->flags);
		push_longint(fio->unget);
		push_longint(fio->alloc);
		push_longint(fio->buffincrement);
		push_LIST_TAG();
		VarStore(SYMSTR("n"),STOF_ESI,0,top_estack);
		break;

The WriteListToFilePtr function writes back to the FILE structure:

Code: [Select]

void WriteListToFilePtr(ESI temp,FILE* fio)
{
	int i=0;
	long* u=NULL;
	if (!(u=calloc(7,sizeof(long))))
	return;
	//clrscr();
	for(i=0;i<7;i++)
	{
		u[i]=GetIntArg(temp);
		//printf("u[%d]=%ld\n",i,u[i]);
	}
	

	fio->fpos=(char*)u[6];
	fio->base=(void*)u[5];
	fio->handle=u[4];
	fio->flags=u[3];
	fio->unget=u[2];
	fio->alloc=u[1];
	fio->buffincrement=u[0];
	free(u);
}

Do these entries in the structure have to be written to in reverse order or is this order fine? Also, thanks for your help!

Lionel Debroux · « **Reply #16 on:** June 06, 2012, 03:11:00 pm »

The order doesn't matter, but I'm not sure why you're serializing and deserializing the FILE structure's fields ?

BTW: all files on the TI-68k are memory-mapped, BTW, so it's more efficient to use native, non-standard vat.h functions than standard, non-native stdio.h functions (reimplemented on top of vat.h, so they take up some space in your program)

blue_bear_94 · « **Reply #17 on:** June 06, 2012, 03:15:36 pm »

I'm serializing/deserializing the fields so that the user will be able to open and close with the same FILE structure. Also, note that this is code from a library I'm writing. The problem is that this code gives me an address error:

Code: [Select]

case 25:
		a=GetArgType(argptr);
		if (a!=LIST_TAG)
		{
			DlgError("Arg 2 must be list");
			return;
		}
		WriteListToFilePtr(argptr-1,fio);
		fclose(fio);

fio is a pointer to the FILE structure declared before the switch statement.

Lionel Debroux · « **Reply #18 on:** June 07, 2012, 01:59:03 am »

Quote

I'm serializing/deserializing the fields so that the user will be able to open and close with the same FILE structure.

Yeah, that's what I had understood from the code, but I'm trying to understand why do you need / want to do that ?

The general rule for fields of a FILE struct, whatever the target platform is, is that these fields are an implementation detail and should not be used, unless there's a very good reason to.
Serializing FILE structs in order to be able to deserialize them, potentially from a different run, is a recipe for disaster if the file's parameters (starting with the addresses - files can move during a both heap compaction and an archive memory garbage collection) change in-between.

blue_bear_94 · « **Reply #19 on:** June 07, 2012, 09:53:41 am »

Then I might replace fopen/fclose/fgetc/fputc with 4 file commands: fread, fwrite, fgetc, and fputc. Thanks for telling me that!
EDIT: Does the handle field (fio->handle) remain consistent between runs though?

Lionel Debroux · « **Reply #20 on:** June 07, 2012, 09:59:50 am »

Quote

Then I might replace fopen/fclose/fgetc/fputc with 4 file commands: fread, fwrite, fgetc, and fputc. Thanks for telling me that!

Hmm, I don't follow you ?

blue_bear_94 · « **Reply #21 on:** June 15, 2012, 11:09:28 am »

On 2nd thought, I am going to use an array of 16 FILE structures, and have the user refer to them by indices (0 to 15). With any file-writing operation, I will update the appropriate element. For fopen and fclose, I might have

Code: [Select]

case 24:
		a=GetArgType(argptr);
		if (a!=STR_TAG)
		{
			DlgError("Arg 2 must be string");
			return;
		}
		const char* f3=GetStrnArg(argptr);
		a=GetArgType(argptr);
		if (a!=STR_TAG)
		{
			DlgError("Arg 3 must be string");
			return;
		}
		const char* f4=GetStrnArg(argptr);
		a=GetArgType(argptr);
		for (x=0;x<=16;x++)
		{
			if (!interface[x].handle) break;
		}
		if (x!=16)
		{
			interface[x]=*fopen(f3,f4);
		}
		WriteToNInt(x);
		break;
		case 25:
		a=GetArgType(argptr);
		if (a!=POSINT_TAG)
		{
			DlgError("Arg 2 must be int");
			return;
		}
		x=GetIntArg(argptr);
		if (x<0||x>=16)
		{
			DlgError("Arg 2 out of range");
			return;
		}
		fclose(&interface[x]);
		interface[x].handle=H_NULL;
		break;

Lionel Debroux · « **Reply #22 on:** June 15, 2012, 12:55:37 pm »

Quote

EDIT: Does the handle field (fio->handle) remain consistent between runs though?

Not in the general case. That's part of the reasons why I'm suggesting you to avoid using the fields of the FILE struct.

blue_bear_94 · « **Reply #23 on:** June 18, 2012, 03:00:10 pm »

For some reason the code after "case 25:" results in an Address Error...

Author Topic: [68k] Storing a value into n? (Read 12207 times)

blue_bear_94

Re: [68k] Storing a value into n?

Lionel Debroux

Re: [68k] Storing a value into n?

blue_bear_94

Re: [68k] Storing a value into n?

Lionel Debroux

Re: [68k] Storing a value into n?

blue_bear_94

Re: [68k] Storing a value into n?

Lionel Debroux

Re: [68k] Storing a value into n?

blue_bear_94

Re: [68k] Storing a value into n?

Lionel Debroux

Re: [68k] Storing a value into n?

blue_bear_94

Re: [68k] Storing a value into n?