Author Topic: [68k] Storing a value into n? (Read 11126 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 11126 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?