12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061 |
- - Shadow bytes with internal values
- The biggest problem with the interpreter is that undefinedness is not
- transitive. A warning is given if an undefined value is used, but then the
- interpreter goes on to use the (zero) value as if nothing had happened. The
- reason is that internal values in the interpreter have no shadow bytes, and
- consequently the undefinedness is lost as soon as a value is passed to an
- operation. Likewise the type is lost, which makes it impossible to do good
- type cheking on pointers. If internal values would have a shadow byte (only
- one per values is needed), we could have a shadow bit signifying "derives from
- null pointer", which could be checked when the pointer is dereferenced.
- Presently only the value of the pointer is checked.
- - Name generation upon forking.
- At present there is an ad-hoc mechanism for generating new file names for
- int.log and int.mess and a new variable name for LOG= upon forking. This
- mechanism is not well localized and does not generalize immediately to other
- file names like int.tally and int.core. Another consequence is that the AT=
- facility is presently implemented as a patch.
- - Integration of memory access
- Presently each memory access consists of at least three calls, one to check
- the shadow byte, one to store the data and one to rewrite or update the shadow
- byte; each of these do the same address evaluations etc. There should
- probably be routines for integrated writing and reading of bytes.
- - Improvements of warnings
- Presently warnings are indicated by a single number, in warn.h. This is often
- too little information. The warning should be a printf format, and warning()
- should accept a variable number of parameters.
- - There seems to be no way of obtaining the largest possible double
- on a machine in a system-independent way (except, perhaps, for including
- <math.h>). For the time being there is a #define MAXDOUBLE in do_fpar.c.
- - Program to process the int.tally file
- - Program to process int.core; also, define a more proper format for the
- int.core file.
- - Some esthetic problems
- - The system call umount is called unmount on some systems, or
- even called differently in different libraries on the same
- system. It is not clear to me who is to blame, nor if that
- would help.
- [[
- Proposed code to be generated by mkswitch.c;
- type to be had from /ur/em/etc/em_table.
- DoXXX[01](par) long par { type arg = (LOG(("@X9 XXX %lt", par)), arg_t(par)); }
- ]]
|