This commit was manufactured by cvs2svn to create tag 'rtems-3-6-0'.3.6.0

Sprout from master 1996-09-30 20:15:01 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'fixed incorrect placement of CPU_STRUCTURE_ALIGNMENT macro.' Delete: c/build-tools/README c/build-tools/cklength.c c/build-tools/eolstrip.c c/build-tools/packhex.c c/build-tools/unhex.c c/src/exec/libcsupport/include/clockdrv.h c/src/exec/libcsupport/include/console.h c/src/exec/libcsupport/include/iosupp.h c/src/exec/libcsupport/include/ringbuf.h c/src/exec/libcsupport/include/rtems/assoc.h c/src/exec/libcsupport/include/rtems/error.h c/src/exec/libcsupport/include/rtems/libcsupport.h c/src/exec/libcsupport/include/rtems/libio.h c/src/exec/libcsupport/include/spurious.h c/src/exec/libcsupport/include/sys/utsname.h c/src/exec/libcsupport/include/timerdrv.h c/src/exec/libcsupport/include/vmeintr.h c/src/exec/libcsupport/src/README c/src/exec/libcsupport/src/__brk.c c/src/exec/libcsupport/src/__gettod.c c/src/exec/libcsupport/src/__times.c c/src/exec/libcsupport/src/assoc.c c/src/exec/libcsupport/src/error.c c/src/exec/libcsupport/src/hosterr.c c/src/exec/libcsupport/src/libio.c c/src/exec/libcsupport/src/malloc.c c/src/exec/libcsupport/src/newlibc.c c/src/exec/libcsupport/src/no_libc.c c/src/exec/libcsupport/src/unixlibc.c c/src/exec/libcsupport/src/utsname.c c/src/exec/posix/include/limits.h c/src/exec/posix/include/rtems/posix/cancel.h c/src/exec/posix/include/rtems/posix/cond.h c/src/exec/posix/include/rtems/posix/condmp.h c/src/exec/posix/include/rtems/posix/config.h c/src/exec/posix/include/rtems/posix/intr.h c/src/exec/posix/include/rtems/posix/key.h c/src/exec/posix/include/rtems/posix/mqueue.h c/src/exec/posix/include/rtems/posix/mqueuemp.h c/src/exec/posix/include/rtems/posix/mutex.h c/src/exec/posix/include/rtems/posix/mutexmp.h c/src/exec/posix/include/rtems/posix/posixapi.h c/src/exec/posix/include/rtems/posix/priority.h c/src/exec/posix/include/rtems/posix/psignal.h c/src/exec/posix/include/rtems/posix/pthread.h c/src/exec/posix/include/rtems/posix/pthreadmp.h c/src/exec/posix/include/rtems/posix/semaphore.h c/src/exec/posix/include/rtems/posix/semaphoremp.h c/src/exec/posix/include/rtems/posix/seterr.h c/src/exec/posix/include/rtems/posix/threadsup.h c/src/exec/posix/include/rtems/posix/time.h c/src/exec/posix/include/sys/utsname.h c/src/exec/rtems/include/rtems.h c/src/exec/rtems/include/rtems/rtems/asr.h c/src/exec/rtems/include/rtems/rtems/attr.h c/src/exec/rtems/include/rtems/rtems/clock.h c/src/exec/rtems/include/rtems/rtems/config.h c/src/exec/rtems/include/rtems/rtems/dpmem.h c/src/exec/rtems/include/rtems/rtems/event.h c/src/exec/rtems/include/rtems/rtems/eventmp.h c/src/exec/rtems/include/rtems/rtems/eventset.h c/src/exec/rtems/include/rtems/rtems/intr.h c/src/exec/rtems/include/rtems/rtems/message.h c/src/exec/rtems/include/rtems/rtems/modes.h c/src/exec/rtems/include/rtems/rtems/mp.h c/src/exec/rtems/include/rtems/rtems/msgmp.h c/src/exec/rtems/include/rtems/rtems/options.h c/src/exec/rtems/include/rtems/rtems/part.h c/src/exec/rtems/include/rtems/rtems/partmp.h c/src/exec/rtems/include/rtems/rtems/ratemon.h c/src/exec/rtems/include/rtems/rtems/region.h c/src/exec/rtems/include/rtems/rtems/regionmp.h c/src/exec/rtems/include/rtems/rtems/rtemsapi.h c/src/exec/rtems/include/rtems/rtems/sem.h c/src/exec/rtems/include/rtems/rtems/semmp.h c/src/exec/rtems/include/rtems/rtems/signal.h c/src/exec/rtems/include/rtems/rtems/signalmp.h c/src/exec/rtems/include/rtems/rtems/status.h c/src/exec/rtems/include/rtems/rtems/support.h c/src/exec/rtems/include/rtems/rtems/taskmp.h c/src/exec/rtems/include/rtems/rtems/tasks.h c/src/exec/rtems/include/rtems/rtems/timer.h c/src/exec/rtems/include/rtems/rtems/types.h c/src/exec/rtems/inline/rtems/rtems/asr.inl c/src/exec/rtems/inline/rtems/rtems/attr.inl c/src/exec/rtems/inline/rtems/rtems/dpmem.inl c/src/exec/rtems/inline/rtems/rtems/event.inl c/src/exec/rtems/inline/rtems/rtems/eventset.inl c/src/exec/rtems/inline/rtems/rtems/message.inl c/src/exec/rtems/inline/rtems/rtems/modes.inl c/src/exec/rtems/inline/rtems/rtems/options.inl c/src/exec/rtems/inline/rtems/rtems/part.inl c/src/exec/rtems/inline/rtems/rtems/ratemon.inl c/src/exec/rtems/inline/rtems/rtems/region.inl c/src/exec/rtems/inline/rtems/rtems/sem.inl c/src/exec/rtems/inline/rtems/rtems/status.inl c/src/exec/rtems/inline/rtems/rtems/support.inl c/src/exec/rtems/inline/rtems/rtems/tasks.inl c/src/exec/rtems/inline/rtems/rtems/timer.inl c/src/exec/rtems/macros/rtems/rtems/asr.inl c/src/exec/rtems/macros/rtems/rtems/attr.inl c/src/exec/rtems/macros/rtems/rtems/dpmem.inl c/src/exec/rtems/macros/rtems/rtems/event.inl c/src/exec/rtems/macros/rtems/rtems/eventset.inl c/src/exec/rtems/macros/rtems/rtems/message.inl c/src/exec/rtems/macros/rtems/rtems/modes.inl c/src/exec/rtems/macros/rtems/rtems/options.inl c/src/exec/rtems/macros/rtems/rtems/part.inl c/src/exec/rtems/macros/rtems/rtems/ratemon.inl c/src/exec/rtems/macros/rtems/rtems/region.inl c/src/exec/rtems/macros/rtems/rtems/sem.inl c/src/exec/rtems/macros/rtems/rtems/status.inl c/src/exec/rtems/macros/rtems/rtems/support.inl c/src/exec/rtems/macros/rtems/rtems/tasks.inl c/src/exec/rtems/macros/rtems/rtems/timer.inl c/src/exec/rtems/src/rtclock.c c/src/exec/rtems/src/rtemstimer.c c/src/exec/sapi/headers/confdefs.h c/src/exec/sapi/include/confdefs.h c/src/exec/sapi/include/rtems/config.h c/src/exec/sapi/include/rtems/directives.h c/src/exec/sapi/include/rtems/extension.h c/src/exec/sapi/include/rtems/fatal.h c/src/exec/sapi/include/rtems/init.h c/src/exec/sapi/include/rtems/io.h c/src/exec/sapi/include/rtems/mptables.h c/src/exec/sapi/include/rtems/sptables.h c/src/exec/sapi/inline/rtems/extension.inl c/src/exec/sapi/macros/rtems/extension.inl c/src/exec/sapi/src/exinit.c c/src/exec/score/cpu/hppa1.1/cpu.c c/src/exec/score/cpu/hppa1.1/cpu.h c/src/exec/score/cpu/hppa1.1/cpu_asm.h c/src/exec/score/cpu/hppa1.1/cpu_asm.s c/src/exec/score/cpu/hppa1.1/hppa.h c/src/exec/score/cpu/hppa1.1/hppatypes.h c/src/exec/score/cpu/hppa1.1/rtems.s c/src/exec/score/cpu/mips/asm.h c/src/exec/score/cpu/mips/cpu.c c/src/exec/score/cpu/mips/cpu_asm.S c/src/exec/score/cpu/mips/cpu_asm.h c/src/exec/score/cpu/mips/idtcpu.h c/src/exec/score/cpu/mips/idtmon.h c/src/exec/score/cpu/mips/iregdef.h c/src/exec/score/cpu/mips/rtems.c c/src/exec/score/cpu/powerpc/README c/src/exec/score/cpu/powerpc/TODO c/src/exec/score/cpu/powerpc/cpu.c c/src/exec/score/cpu/powerpc/cpu.h c/src/exec/score/cpu/powerpc/cpu_asm.s c/src/exec/score/cpu/powerpc/irq_stub.s c/src/exec/score/cpu/powerpc/ppc.h c/src/exec/score/cpu/powerpc/ppctypes.h c/src/exec/score/cpu/powerpc/rtems.s c/src/exec/score/include/rtems/debug.h c/src/exec/score/include/rtems/score/address.h c/src/exec/score/include/rtems/score/apiext.h c/src/exec/score/include/rtems/score/bitfield.h c/src/exec/score/include/rtems/score/chain.h c/src/exec/score/include/rtems/score/context.h c/src/exec/score/include/rtems/score/copyrt.h c/src/exec/score/include/rtems/score/coremsg.h c/src/exec/score/include/rtems/score/coremutex.h c/src/exec/score/include/rtems/score/coresem.h c/src/exec/score/include/rtems/score/heap.h c/src/exec/score/include/rtems/score/interr.h c/src/exec/score/include/rtems/score/isr.h c/src/exec/score/include/rtems/score/mpci.h c/src/exec/score/include/rtems/score/mppkt.h c/src/exec/score/include/rtems/score/object.h c/src/exec/score/include/rtems/score/objectmp.h c/src/exec/score/include/rtems/score/priority.h c/src/exec/score/include/rtems/score/stack.h c/src/exec/score/include/rtems/score/states.h c/src/exec/score/include/rtems/score/sysstate.h c/src/exec/score/include/rtems/score/thread.h c/src/exec/score/include/rtems/score/threadmp.h c/src/exec/score/include/rtems/score/threadq.h c/src/exec/score/include/rtems/score/tod.h c/src/exec/score/include/rtems/score/tqdata.h c/src/exec/score/include/rtems/score/userext.h c/src/exec/score/include/rtems/score/watchdog.h c/src/exec/score/include/rtems/score/wkspace.h c/src/exec/score/include/rtems/system.h c/src/exec/score/inline/rtems/score/address.inl c/src/exec/score/inline/rtems/score/chain.inl c/src/exec/score/inline/rtems/score/coremsg.inl c/src/exec/score/inline/rtems/score/coremutex.inl c/src/exec/score/inline/rtems/score/coresem.inl c/src/exec/score/inline/rtems/score/heap.inl c/src/exec/score/inline/rtems/score/isr.inl c/src/exec/score/inline/rtems/score/mppkt.inl c/src/exec/score/inline/rtems/score/object.inl c/src/exec/score/inline/rtems/score/objectmp.inl c/src/exec/score/inline/rtems/score/priority.inl c/src/exec/score/inline/rtems/score/stack.inl c/src/exec/score/inline/rtems/score/states.inl c/src/exec/score/inline/rtems/score/sysstate.inl c/src/exec/score/inline/rtems/score/thread.inl c/src/exec/score/inline/rtems/score/threadmp.inl c/src/exec/score/inline/rtems/score/tod.inl c/src/exec/score/inline/rtems/score/tqdata.inl c/src/exec/score/inline/rtems/score/userext.inl c/src/exec/score/inline/rtems/score/watchdog.inl c/src/exec/score/inline/rtems/score/wkspace.inl c/src/exec/score/macros/rtems/score/README c/src/exec/score/macros/rtems/score/address.inl c/src/exec/score/macros/rtems/score/chain.inl c/src/exec/score/macros/rtems/score/coremsg.inl c/src/exec/score/macros/rtems/score/coremutex.inl c/src/exec/score/macros/rtems/score/coresem.inl c/src/exec/score/macros/rtems/score/heap.inl c/src/exec/score/macros/rtems/score/isr.inl c/src/exec/score/macros/rtems/score/mppkt.inl c/src/exec/score/macros/rtems/score/object.inl c/src/exec/score/macros/rtems/score/objectmp.inl c/src/exec/score/macros/rtems/score/priority.inl c/src/exec/score/macros/rtems/score/stack.inl c/src/exec/score/macros/rtems/score/states.inl c/src/exec/score/macros/rtems/score/sysstate.inl c/src/exec/score/macros/rtems/score/thread.inl c/src/exec/score/macros/rtems/score/threadmp.inl c/src/exec/score/macros/rtems/score/tod.inl c/src/exec/score/macros/rtems/score/tqdata.inl c/src/exec/score/macros/rtems/score/userext.inl c/src/exec/score/macros/rtems/score/watchdog.inl c/src/exec/score/macros/rtems/score/wkspace.inl c/src/exec/score/src/coretod.c c/src/exec/score/tools/hppa1.1/genoffsets.c c/src/lib/include/rtems/assoc.h c/src/lib/include/rtems/error.h c/src/lib/include/rtems/libcsupport.h c/src/lib/include/rtems/libio.h c/src/lib/include/sys/utsname.h c/src/lib/libbsp/hppa1.1/pxfl/README c/src/lib/libbsp/hppa1.1/pxfl/floss-bsp.h c/src/lib/libbsp/hppa1.1/simhppa/include/bsp.h c/src/lib/libbsp/hppa1.1/simhppa/include/coverhd.h c/src/lib/libbsp/hppa1.1/simhppa/include/ttydrv.h c/src/lib/libbsp/hppa1.1/simhppa/shmsupp/README c/src/lib/libbsp/hppa1.1/simhppa/shmsupp/addrconv.c c/src/lib/libbsp/hppa1.1/simhppa/shmsupp/getcfg.c c/src/lib/libbsp/hppa1.1/simhppa/shmsupp/intr.c c/src/lib/libbsp/hppa1.1/simhppa/shmsupp/lock.c c/src/lib/libbsp/hppa1.1/simhppa/shmsupp/mpisr.c c/src/lib/libbsp/hppa1.1/simhppa/startup/bspclean.c c/src/lib/libbsp/hppa1.1/simhppa/startup/bspstart.c c/src/lib/libbsp/hppa1.1/simhppa/startup/setvec.c c/src/lib/libbsp/hppa1.1/simhppa/times c/src/lib/libbsp/hppa1.1/simhppa/tools/print_dump.c c/src/lib/libbsp/hppa1.1/simhppa/tty/tty.c c/src/lib/libbsp/mips/p4000/README c/src/lib/libbsp/mips/p4000/console/console.c c/src/lib/libbsp/mips/p4000/console/led.S c/src/lib/libbsp/mips/p4000/include/bsp.h c/src/lib/libbsp/mips/p4000/include/coverhd.h c/src/lib/libbsp/mips/p4000/liblnk/lnklib.S c/src/lib/libbsp/mips/p4000/start/start.S c/src/lib/libbsp/mips/p4000/startup/bspclean.c c/src/lib/libbsp/mips/p4000/startup/ghlinkcmds c/src/lib/libbsp/mips/p4000/startup/idtmem.S c/src/lib/libbsp/mips/p4000/startup/idttlb.S c/src/lib/libbsp/mips/p4000/startup/inittlb.c c/src/lib/libbsp/mips/p4000/startup/linkcmds c/src/lib/libbsp/mips/p4000/startup/setvec.c c/src/lib/libbsp/mips/p4000/times c/src/lib/libbsp/powerpc/papyrus/README c/src/lib/libbsp/powerpc/papyrus/dlentry/dlentry.s c/src/lib/libbsp/powerpc/papyrus/flashentry/flashentry.s c/src/lib/libbsp/powerpc/papyrus/include/bsp.h c/src/lib/libbsp/powerpc/papyrus/include/coverhd.h c/src/lib/libbsp/powerpc/papyrus/startup/bspclean.c c/src/lib/libbsp/powerpc/papyrus/startup/bspstart.c c/src/lib/libbsp/powerpc/papyrus/startup/linkcmds c/src/lib/libbsp/powerpc/papyrus/startup/setvec.c c/src/lib/libbsp/powerpc/papyrus/times c/src/lib/libc/utsname.c c/src/lib/libcpu/hppa1.1/clock/clock.c c/src/lib/libcpu/hppa1.1/runway/runway.h c/src/lib/libcpu/hppa1.1/semaphore/semaphore.c c/src/lib/libcpu/hppa1.1/semaphore/semaphore.h c/src/lib/libcpu/hppa1.1/timer/timer.c c/src/lib/libcpu/mips/clock/ckinit.c c/src/lib/libcpu/mips/clock/clock.S c/src/lib/libcpu/mips/clock/clock.h c/src/lib/libcpu/mips/timer/gettime.S c/src/lib/libcpu/mips/timer/timer.c c/src/lib/libcpu/powerpc/README c/src/lib/libcpu/powerpc/ppc403/README c/src/lib/libcpu/powerpc/ppc403/clock/clock.c c/src/lib/libcpu/powerpc/ppc403/console/console.c c/src/lib/libcpu/powerpc/ppc403/timer/timer.c c/src/lib/libcpu/powerpc/ppc403/vectors/README c/src/lib/libcpu/powerpc/ppc403/vectors/align_h.s c/src/lib/libcpu/powerpc/ppc403/vectors/vectors.s c/src/lib/libcpu/sparc/include/erc32.h c/src/libchip/shmdr/README c/src/libchip/shmdr/addlq.c c/src/libchip/shmdr/cnvpkt.c c/src/libchip/shmdr/dump.c c/src/libchip/shmdr/fatal.c c/src/libchip/shmdr/getlq.c c/src/libchip/shmdr/getpkt.c c/src/libchip/shmdr/init.c c/src/libchip/shmdr/initlq.c c/src/libchip/shmdr/intr.c c/src/libchip/shmdr/mpci.h c/src/libchip/shmdr/mpisr.c c/src/libchip/shmdr/poll.c c/src/libchip/shmdr/receive.c c/src/libchip/shmdr/retpkt.c c/src/libchip/shmdr/send.c c/src/libchip/shmdr/setckvec.c c/src/libchip/shmdr/shm_driver.h c/src/optman/rtems/no-dpmem.c c/src/optman/rtems/no-event.c c/src/optman/rtems/no-mp.c c/src/optman/rtems/no-msg.c c/src/optman/rtems/no-part.c c/src/optman/rtems/no-region.c c/src/optman/rtems/no-rtmon.c c/src/optman/rtems/no-sem.c c/src/optman/rtems/no-signal.c c/src/optman/rtems/no-timer.c c/src/optman/sapi/no-ext.c c/src/optman/sapi/no-io.c cpukit/libcsupport/include/clockdrv.h cpukit/libcsupport/include/console.h cpukit/libcsupport/include/iosupp.h cpukit/libcsupport/include/ringbuf.h cpukit/libcsupport/include/rtems/assoc.h cpukit/libcsupport/include/rtems/error.h cpukit/libcsupport/include/rtems/libcsupport.h cpukit/libcsupport/include/rtems/libio.h cpukit/libcsupport/include/spurious.h cpukit/libcsupport/include/sys/utsname.h cpukit/libcsupport/include/timerdrv.h cpukit/libcsupport/include/vmeintr.h cpukit/libcsupport/src/README cpukit/libcsupport/src/__brk.c cpukit/libcsupport/src/__gettod.c cpukit/libcsupport/src/__times.c cpukit/libcsupport/src/assoc.c cpukit/libcsupport/src/error.c cpukit/libcsupport/src/hosterr.c cpukit/libcsupport/src/libio.c cpukit/libcsupport/src/malloc.c cpukit/libcsupport/src/newlibc.c cpukit/libcsupport/src/no_libc.c cpukit/libcsupport/src/unixlibc.c cpukit/libcsupport/src/utsname.c cpukit/libmisc/README cpukit/libmisc/monitor/README cpukit/libmisc/monitor/mon-command.c cpukit/libmisc/monitor/mon-config.c cpukit/libmisc/monitor/mon-dname.c cpukit/libmisc/monitor/mon-driver.c cpukit/libmisc/monitor/mon-extension.c cpukit/libmisc/monitor/mon-itask.c cpukit/libmisc/monitor/mon-manager.c cpukit/libmisc/monitor/mon-monitor.c cpukit/libmisc/monitor/mon-mpci.c cpukit/libmisc/monitor/mon-object.c cpukit/libmisc/monitor/mon-prmisc.c cpukit/libmisc/monitor/mon-queue.c cpukit/libmisc/monitor/mon-server.c cpukit/libmisc/monitor/mon-symbols.c cpukit/libmisc/monitor/mon-task.c cpukit/libmisc/monitor/monitor.h cpukit/libmisc/monitor/symbols.h cpukit/libmisc/stackchk/README cpukit/libmisc/stackchk/check.c cpukit/libmisc/stackchk/internal.h cpukit/libmisc/stackchk/stackchk.h cpukit/posix/include/aio.h cpukit/posix/include/devctl.h cpukit/posix/include/intr.h cpukit/posix/include/mqueue.h cpukit/posix/include/rtems/posix/cancel.h cpukit/posix/include/rtems/posix/cond.h cpukit/posix/include/rtems/posix/condmp.h cpukit/posix/include/rtems/posix/config.h cpukit/posix/include/rtems/posix/intr.h cpukit/posix/include/rtems/posix/key.h cpukit/posix/include/rtems/posix/mqueue.h cpukit/posix/include/rtems/posix/mqueuemp.h cpukit/posix/include/rtems/posix/mutex.h cpukit/posix/include/rtems/posix/mutexmp.h cpukit/posix/include/rtems/posix/posixapi.h cpukit/posix/include/rtems/posix/priority.h cpukit/posix/include/rtems/posix/psignal.h cpukit/posix/include/rtems/posix/pthread.h cpukit/posix/include/rtems/posix/pthreadmp.h cpukit/posix/include/rtems/posix/semaphore.h cpukit/posix/include/rtems/posix/semaphoremp.h cpukit/posix/include/rtems/posix/threadsup.h cpukit/posix/include/rtems/posix/time.h cpukit/posix/include/sched.h cpukit/posix/include/semaphore.h cpukit/posix/inline/rtems/posix/cond.inl cpukit/posix/inline/rtems/posix/intr.inl cpukit/posix/inline/rtems/posix/key.inl cpukit/posix/inline/rtems/posix/mqueue.inl cpukit/posix/inline/rtems/posix/mutex.inl cpukit/posix/inline/rtems/posix/priority.inl cpukit/posix/inline/rtems/posix/pthread.inl cpukit/posix/inline/rtems/posix/semaphore.inl cpukit/posix/src/adasupp.c cpukit/posix/src/aio.c cpukit/posix/src/cancel.c cpukit/posix/src/cond.c cpukit/posix/src/devctl.c cpukit/posix/src/intr.c cpukit/posix/src/key.c cpukit/posix/src/mqueue.c cpukit/posix/src/mutex.c cpukit/posix/src/psignal.c cpukit/posix/src/pthread.c cpukit/posix/src/ptimer.c cpukit/posix/src/sched.c cpukit/posix/src/semaphore.c cpukit/posix/src/time.c cpukit/posix/src/types.c cpukit/rtems/include/rtems.h cpukit/rtems/include/rtems/rtems/asr.h cpukit/rtems/include/rtems/rtems/attr.h cpukit/rtems/include/rtems/rtems/clock.h cpukit/rtems/include/rtems/rtems/config.h cpukit/rtems/include/rtems/rtems/dpmem.h cpukit/rtems/include/rtems/rtems/event.h cpukit/rtems/include/rtems/rtems/eventmp.h cpukit/rtems/include/rtems/rtems/eventset.h cpukit/rtems/include/rtems/rtems/intr.h cpukit/rtems/include/rtems/rtems/message.h cpukit/rtems/include/rtems/rtems/modes.h cpukit/rtems/include/rtems/rtems/mp.h cpukit/rtems/include/rtems/rtems/msgmp.h cpukit/rtems/include/rtems/rtems/options.h cpukit/rtems/include/rtems/rtems/part.h cpukit/rtems/include/rtems/rtems/partmp.h cpukit/rtems/include/rtems/rtems/ratemon.h cpukit/rtems/include/rtems/rtems/region.h cpukit/rtems/include/rtems/rtems/regionmp.h cpukit/rtems/include/rtems/rtems/rtemsapi.h cpukit/rtems/include/rtems/rtems/sem.h cpukit/rtems/include/rtems/rtems/semmp.h cpukit/rtems/include/rtems/rtems/signal.h cpukit/rtems/include/rtems/rtems/signalmp.h cpukit/rtems/include/rtems/rtems/status.h cpukit/rtems/include/rtems/rtems/support.h cpukit/rtems/include/rtems/rtems/taskmp.h cpukit/rtems/include/rtems/rtems/tasks.h cpukit/rtems/include/rtems/rtems/timer.h cpukit/rtems/include/rtems/rtems/types.h cpukit/rtems/inline/rtems/rtems/asr.inl cpukit/rtems/inline/rtems/rtems/attr.inl cpukit/rtems/inline/rtems/rtems/dpmem.inl cpukit/rtems/inline/rtems/rtems/event.inl cpukit/rtems/inline/rtems/rtems/eventset.inl cpukit/rtems/inline/rtems/rtems/message.inl cpukit/rtems/inline/rtems/rtems/modes.inl cpukit/rtems/inline/rtems/rtems/options.inl cpukit/rtems/inline/rtems/rtems/part.inl cpukit/rtems/inline/rtems/rtems/ratemon.inl cpukit/rtems/inline/rtems/rtems/region.inl cpukit/rtems/inline/rtems/rtems/sem.inl cpukit/rtems/inline/rtems/rtems/status.inl cpukit/rtems/inline/rtems/rtems/support.inl cpukit/rtems/inline/rtems/rtems/tasks.inl cpukit/rtems/inline/rtems/rtems/timer.inl cpukit/rtems/macros/rtems/rtems/asr.inl cpukit/rtems/macros/rtems/rtems/attr.inl cpukit/rtems/macros/rtems/rtems/dpmem.inl cpukit/rtems/macros/rtems/rtems/event.inl cpukit/rtems/macros/rtems/rtems/eventset.inl cpukit/rtems/macros/rtems/rtems/message.inl cpukit/rtems/macros/rtems/rtems/modes.inl cpukit/rtems/macros/rtems/rtems/options.inl cpukit/rtems/macros/rtems/rtems/part.inl cpukit/rtems/macros/rtems/rtems/ratemon.inl cpukit/rtems/macros/rtems/rtems/region.inl cpukit/rtems/macros/rtems/rtems/sem.inl cpukit/rtems/macros/rtems/rtems/status.inl cpukit/rtems/macros/rtems/rtems/support.inl cpukit/rtems/macros/rtems/rtems/tasks.inl cpukit/rtems/macros/rtems/rtems/timer.inl cpukit/rtems/src/dpmem.c cpukit/rtems/src/event.c cpukit/rtems/src/eventmp.c cpukit/rtems/src/intr.c cpukit/rtems/src/mp.c cpukit/rtems/src/msg.c cpukit/rtems/src/msgmp.c cpukit/rtems/src/part.c cpukit/rtems/src/partmp.c cpukit/rtems/src/ratemon.c cpukit/rtems/src/region.c cpukit/rtems/src/regionmp.c cpukit/rtems/src/rtclock.c cpukit/rtems/src/rtemstimer.c cpukit/rtems/src/sem.c cpukit/rtems/src/semmp.c cpukit/rtems/src/signal.c cpukit/rtems/src/signalmp.c cpukit/rtems/src/taskmp.c cpukit/rtems/src/tasks.c cpukit/sapi/include/confdefs.h cpukit/sapi/include/rtems/config.h cpukit/sapi/include/rtems/extension.h cpukit/sapi/include/rtems/fatal.h cpukit/sapi/include/rtems/init.h cpukit/sapi/include/rtems/io.h cpukit/sapi/include/rtems/mptables.h cpukit/sapi/inline/rtems/extension.inl cpukit/sapi/macros/rtems/extension.inl cpukit/sapi/src/debug.c cpukit/sapi/src/exinit.c cpukit/sapi/src/extension.c cpukit/sapi/src/fatal.c cpukit/sapi/src/io.c cpukit/sapi/src/posixapi.c cpukit/sapi/src/rtemsapi.c cpukit/score/cpu/a29k/amd.ah cpukit/score/cpu/a29k/asm.h cpukit/score/cpu/a29k/cpu.c cpukit/score/cpu/a29k/pswmacro.ah cpukit/score/cpu/hppa1.1/cpu.c cpukit/score/cpu/i386/asm.h cpukit/score/cpu/i386/cpu.c cpukit/score/cpu/i386/rtems/asm.h cpukit/score/cpu/i960/asm.h cpukit/score/cpu/i960/cpu.c cpukit/score/cpu/m68k/asm.h cpukit/score/cpu/m68k/cpu.c cpukit/score/cpu/m68k/m68302.h cpukit/score/cpu/m68k/m68360.h cpukit/score/cpu/m68k/qsm.h cpukit/score/cpu/m68k/rtems/asm.h cpukit/score/cpu/m68k/rtems/m68k/m68302.h cpukit/score/cpu/m68k/rtems/m68k/m68360.h cpukit/score/cpu/m68k/rtems/m68k/qsm.h cpukit/score/cpu/m68k/rtems/m68k/sim.h cpukit/score/cpu/m68k/sim.h cpukit/score/cpu/mips/asm.h cpukit/score/cpu/mips/cpu.c cpukit/score/cpu/mips/cpu_asm.S cpukit/score/cpu/mips/idtcpu.h cpukit/score/cpu/mips/iregdef.h cpukit/score/cpu/mips/rtems/asm.h cpukit/score/cpu/mips/rtems/mips/idtcpu.h cpukit/score/cpu/mips/rtems/mips/iregdef.h cpukit/score/cpu/mips64orion/asm.h cpukit/score/cpu/mips64orion/cpu.c cpukit/score/cpu/mips64orion/cpu_asm.S cpukit/score/cpu/mips64orion/cpu_asm.h cpukit/score/cpu/mips64orion/idtcpu.h cpukit/score/cpu/mips64orion/idtmon.h cpukit/score/cpu/mips64orion/iregdef.h cpukit/score/cpu/no_cpu/asm.h cpukit/score/cpu/no_cpu/cpu.c cpukit/score/cpu/no_cpu/cpu_asm.c cpukit/score/cpu/no_cpu/rtems/asm.h cpukit/score/cpu/sparc/README cpukit/score/cpu/sparc/asm.h cpukit/score/cpu/sparc/cpu.c cpukit/score/cpu/sparc/rtems/asm.h cpukit/score/cpu/unix/cpu.c cpukit/score/include/rtems/debug.h cpukit/score/include/rtems/score/address.h cpukit/score/include/rtems/score/apiext.h cpukit/score/include/rtems/score/bitfield.h cpukit/score/include/rtems/score/chain.h cpukit/score/include/rtems/score/context.h cpukit/score/include/rtems/score/copyrt.h cpukit/score/include/rtems/score/coremsg.h cpukit/score/include/rtems/score/coremutex.h cpukit/score/include/rtems/score/coresem.h cpukit/score/include/rtems/score/heap.h cpukit/score/include/rtems/score/interr.h cpukit/score/include/rtems/score/isr.h cpukit/score/include/rtems/score/mpci.h cpukit/score/include/rtems/score/mppkt.h cpukit/score/include/rtems/score/object.h cpukit/score/include/rtems/score/objectmp.h cpukit/score/include/rtems/score/priority.h cpukit/score/include/rtems/score/stack.h cpukit/score/include/rtems/score/states.h cpukit/score/include/rtems/score/sysstate.h cpukit/score/include/rtems/score/thread.h cpukit/score/include/rtems/score/threadmp.h cpukit/score/include/rtems/score/threadq.h cpukit/score/include/rtems/score/tod.h cpukit/score/include/rtems/score/tqdata.h cpukit/score/include/rtems/score/userext.h cpukit/score/include/rtems/score/watchdog.h cpukit/score/include/rtems/score/wkspace.h cpukit/score/include/rtems/system.h cpukit/score/inline/rtems/score/address.inl cpukit/score/inline/rtems/score/chain.inl cpukit/score/inline/rtems/score/coremsg.inl cpukit/score/inline/rtems/score/coremutex.inl cpukit/score/inline/rtems/score/coresem.inl cpukit/score/inline/rtems/score/heap.inl cpukit/score/inline/rtems/score/isr.inl cpukit/score/inline/rtems/score/mppkt.inl cpukit/score/inline/rtems/score/object.inl cpukit/score/inline/rtems/score/objectmp.inl cpukit/score/inline/rtems/score/priority.inl cpukit/score/inline/rtems/score/stack.inl cpukit/score/inline/rtems/score/states.inl cpukit/score/inline/rtems/score/sysstate.inl cpukit/score/inline/rtems/score/thread.inl cpukit/score/inline/rtems/score/threadmp.inl cpukit/score/inline/rtems/score/tod.inl cpukit/score/inline/rtems/score/tqdata.inl cpukit/score/inline/rtems/score/userext.inl cpukit/score/inline/rtems/score/watchdog.inl cpukit/score/inline/rtems/score/wkspace.inl cpukit/score/macros/README cpukit/score/macros/rtems/score/README cpukit/score/macros/rtems/score/address.inl cpukit/score/macros/rtems/score/chain.inl cpukit/score/macros/rtems/score/coremsg.inl cpukit/score/macros/rtems/score/coremutex.inl cpukit/score/macros/rtems/score/coresem.inl cpukit/score/macros/rtems/score/heap.inl cpukit/score/macros/rtems/score/isr.inl cpukit/score/macros/rtems/score/mppkt.inl cpukit/score/macros/rtems/score/object.inl cpukit/score/macros/rtems/score/objectmp.inl cpukit/score/macros/rtems/score/priority.inl cpukit/score/macros/rtems/score/stack.inl cpukit/score/macros/rtems/score/states.inl cpukit/score/macros/rtems/score/sysstate.inl cpukit/score/macros/rtems/score/thread.inl cpukit/score/macros/rtems/score/threadmp.inl cpukit/score/macros/rtems/score/tod.inl cpukit/score/macros/rtems/score/tqdata.inl cpukit/score/macros/rtems/score/userext.inl cpukit/score/macros/rtems/score/watchdog.inl cpukit/score/macros/rtems/score/wkspace.inl cpukit/score/src/apiext.c cpukit/score/src/chain.c cpukit/score/src/coremsg.c cpukit/score/src/coremutex.c cpukit/score/src/coresem.c cpukit/score/src/coretod.c cpukit/score/src/heap.c cpukit/score/src/interr.c cpukit/score/src/isr.c cpukit/score/src/mpci.c cpukit/score/src/object.c cpukit/score/src/objectmp.c cpukit/score/src/thread.c cpukit/score/src/threadmp.c cpukit/score/src/threadq.c cpukit/score/src/userext.c cpukit/score/src/watchdog.c cpukit/score/src/wkspace.c cpukit/zlib/doc/rfc1950.txt cpukit/zlib/doc/rfc1951.txt cpukit/zlib/doc/rfc1952.txt testsuites/README testsuites/libtests/README testsuites/libtests/malloctest/init.c testsuites/libtests/malloctest/system.h testsuites/libtests/malloctest/task1.c testsuites/libtests/stackchk/blow.c testsuites/libtests/stackchk/init.c testsuites/libtests/stackchk/stackchk.scn testsuites/libtests/stackchk/system.h testsuites/libtests/stackchk/task1.c testsuites/mptests/README testsuites/mptests/mp01/init.c testsuites/mptests/mp01/node1/mp01.doc testsuites/mptests/mp01/node1/mp01.scn testsuites/mptests/mp01/node2/mp01.doc testsuites/mptests/mp01/node2/mp01.scn testsuites/mptests/mp01/system.h testsuites/mptests/mp01/task1.c testsuites/mptests/mp02/init.c testsuites/mptests/mp02/node1/mp02.doc testsuites/mptests/mp02/node1/mp02.scn testsuites/mptests/mp02/node2/mp02.doc testsuites/mptests/mp02/node2/mp02.scn testsuites/mptests/mp02/system.h testsuites/mptests/mp02/task1.c testsuites/mptests/mp03/delay.c testsuites/mptests/mp03/init.c testsuites/mptests/mp03/node1/mp03.doc testsuites/mptests/mp03/node1/mp03.scn testsuites/mptests/mp03/node2/mp03.doc testsuites/mptests/mp03/node2/mp03.scn testsuites/mptests/mp03/system.h testsuites/mptests/mp03/task1.c testsuites/mptests/mp04/init.c testsuites/mptests/mp04/node1/mp04.doc testsuites/mptests/mp04/node1/mp04.scn testsuites/mptests/mp04/node2/mp04.doc testsuites/mptests/mp04/node2/mp04.scn testsuites/mptests/mp04/system.h testsuites/mptests/mp04/task1.c testsuites/mptests/mp05/asr.c testsuites/mptests/mp05/init.c testsuites/mptests/mp05/node1/mp05.doc testsuites/mptests/mp05/node1/mp05.scn testsuites/mptests/mp05/node2/mp05.doc testsuites/mptests/mp05/node2/mp05.scn testsuites/mptests/mp05/system.h testsuites/mptests/mp05/task1.c testsuites/mptests/mp06/init.c testsuites/mptests/mp06/node1/mp06.doc testsuites/mptests/mp06/node1/mp06.scn testsuites/mptests/mp06/node2/mp06.doc testsuites/mptests/mp06/node2/mp06.scn testsuites/mptests/mp06/system.h testsuites/mptests/mp06/task1.c testsuites/mptests/mp07/init.c testsuites/mptests/mp07/node1/mp07.doc testsuites/mptests/mp07/node1/mp07.scn testsuites/mptests/mp07/node2/mp07.doc testsuites/mptests/mp07/node2/mp07.scn testsuites/mptests/mp07/system.h testsuites/mptests/mp07/task1.c testsuites/mptests/mp08/init.c testsuites/mptests/mp08/node1/mp08.doc testsuites/mptests/mp08/node1/mp08.scn testsuites/mptests/mp08/node2/mp08.doc testsuites/mptests/mp08/node2/mp08.scn testsuites/mptests/mp08/system.h testsuites/mptests/mp08/task1.c testsuites/mptests/mp09/init.c testsuites/mptests/mp09/node1/mp09.doc testsuites/mptests/mp09/node1/mp09.scn testsuites/mptests/mp09/node2/mp09.doc testsuites/mptests/mp09/node2/mp09.scn testsuites/mptests/mp09/recvmsg.c testsuites/mptests/mp09/sendmsg.c testsuites/mptests/mp09/system.h testsuites/mptests/mp09/task1.c testsuites/mptests/mp10/init.c testsuites/mptests/mp10/node1/mp10.doc testsuites/mptests/mp10/node1/mp10.scn testsuites/mptests/mp10/node2/mp10.doc testsuites/mptests/mp10/node2/mp10.scn testsuites/mptests/mp10/system.h testsuites/mptests/mp10/task1.c testsuites/mptests/mp10/task2.c testsuites/mptests/mp10/task3.c testsuites/mptests/mp11/init.c testsuites/mptests/mp11/node1/mp11.doc testsuites/mptests/mp11/node1/mp11.scn testsuites/mptests/mp11/node2/mp11.doc testsuites/mptests/mp11/node2/mp11.scn testsuites/mptests/mp11/system.h testsuites/mptests/mp12/init.c testsuites/mptests/mp12/node1/mp12.doc testsuites/mptests/mp12/node1/mp12.scn testsuites/mptests/mp12/node2/mp12.doc testsuites/mptests/mp12/node2/mp12.scn testsuites/mptests/mp12/system.h testsuites/mptests/mp13/init.c testsuites/mptests/mp13/node1/mp13.doc testsuites/mptests/mp13/node1/mp13.scn testsuites/mptests/mp13/node2/mp13.doc testsuites/mptests/mp13/node2/mp13.scn testsuites/mptests/mp13/system.h testsuites/mptests/mp13/task1.c testsuites/mptests/mp13/task2.c testsuites/mptests/mp14/delay.c testsuites/mptests/mp14/evtask1.c testsuites/mptests/mp14/evtmtask.c testsuites/mptests/mp14/exit.c testsuites/mptests/mp14/init.c testsuites/mptests/mp14/msgtask1.c testsuites/mptests/mp14/node1/mp14.doc testsuites/mptests/mp14/node1/mp14.scn testsuites/mptests/mp14/node2/mp14.doc testsuites/mptests/mp14/node2/mp14.scn testsuites/mptests/mp14/pttask1.c testsuites/mptests/mp14/smtask1.c testsuites/mptests/mp14/system.h testsuites/psxtests/include/pmacros.h testsuites/psxtests/psx01/init.c testsuites/psxtests/psx01/psx01.scn testsuites/psxtests/psx01/system.h testsuites/psxtests/psx01/task.c testsuites/psxtests/psx02/init.c testsuites/psxtests/psx02/psx02.scn testsuites/psxtests/psx02/system.h testsuites/psxtests/psx02/task.c testsuites/psxtests/psx03/init.c testsuites/psxtests/psx03/psx03.scn testsuites/psxtests/psx03/system.h testsuites/psxtests/psx03/task.c testsuites/psxtests/psx04/init.c testsuites/psxtests/psx04/psx04.scn testsuites/psxtests/psx04/system.h testsuites/psxtests/psx04/task1.c testsuites/psxtests/psx04/task2.c testsuites/psxtests/psx04/task3.c testsuites/psxtests/psx05/init.c testsuites/psxtests/psx05/psx05.scn testsuites/psxtests/psx05/system.h testsuites/psxtests/psx05/task.c testsuites/psxtests/psx05/task2.c testsuites/psxtests/psx05/task3.c testsuites/psxtests/psx06/init.c testsuites/psxtests/psx06/psx06.scn testsuites/psxtests/psx06/system.h testsuites/psxtests/psx06/task.c testsuites/psxtests/psx06/task2.c testsuites/psxtests/psx07/init.c testsuites/psxtests/psx07/psx07.scn testsuites/psxtests/psx07/system.h testsuites/psxtests/psx07/task.c testsuites/psxtests/psx08/init.c testsuites/psxtests/psx08/psx08.scn testsuites/psxtests/psx08/system.h testsuites/psxtests/psx08/task2.c testsuites/psxtests/psx09/init.c testsuites/psxtests/psx09/psx09.scn testsuites/psxtests/psx09/system.h testsuites/psxtests/psx10/init.c testsuites/psxtests/psx10/psx10.scn testsuites/psxtests/psx10/system.h testsuites/psxtests/psx10/task.c testsuites/psxtests/psx10/task2.c testsuites/psxtests/psx10/task3.c testsuites/psxtests/psx11/init.c testsuites/psxtests/psx11/psx11.scn testsuites/psxtests/psx11/system.h testsuites/psxtests/psx11/task.c testsuites/psxtests/psx12/init.c testsuites/psxtests/psx12/psx12.scn testsuites/psxtests/psx12/system.h testsuites/psxtests/psx12/task.c testsuites/psxtests/psxhdrs/clock01.c testsuites/psxtests/psxhdrs/clock02.c testsuites/psxtests/psxhdrs/clock03.c testsuites/psxtests/psxhdrs/clock04.c testsuites/psxtests/psxhdrs/clock05.c testsuites/psxtests/psxhdrs/clock06.c testsuites/psxtests/psxhdrs/cond01.c testsuites/psxtests/psxhdrs/cond02.c testsuites/psxtests/psxhdrs/cond03.c testsuites/psxtests/psxhdrs/cond04.c testsuites/psxtests/psxhdrs/cond05.c testsuites/psxtests/psxhdrs/cond06.c testsuites/psxtests/psxhdrs/cond07.c testsuites/psxtests/psxhdrs/cond08.c testsuites/psxtests/psxhdrs/cond09.c testsuites/psxtests/psxhdrs/cond10.c testsuites/psxtests/psxhdrs/key01.c testsuites/psxtests/psxhdrs/key02.c testsuites/psxtests/psxhdrs/key03.c testsuites/psxtests/psxhdrs/key04.c testsuites/psxtests/psxhdrs/mutex01.c testsuites/psxtests/psxhdrs/mutex02.c testsuites/psxtests/psxhdrs/mutex03.c testsuites/psxtests/psxhdrs/mutex04.c testsuites/psxtests/psxhdrs/mutex05.c testsuites/psxtests/psxhdrs/mutex06.c testsuites/psxtests/psxhdrs/mutex07.c testsuites/psxtests/psxhdrs/mutex08.c testsuites/psxtests/psxhdrs/mutex09.c testsuites/psxtests/psxhdrs/mutex10.c testsuites/psxtests/psxhdrs/mutex11.c testsuites/psxtests/psxhdrs/mutex12.c testsuites/psxtests/psxhdrs/mutex13.c testsuites/psxtests/psxhdrs/mutex14.c testsuites/psxtests/psxhdrs/mutex15.c testsuites/psxtests/psxhdrs/mutex16.c testsuites/psxtests/psxhdrs/proc01.c testsuites/psxtests/psxhdrs/proc02.c testsuites/psxtests/psxhdrs/proc03.c testsuites/psxtests/psxhdrs/proc04.c testsuites/psxtests/psxhdrs/proc05.c testsuites/psxtests/psxhdrs/proc06.c testsuites/psxtests/psxhdrs/proc07.c testsuites/psxtests/psxhdrs/proc08.c testsuites/psxtests/psxhdrs/proc09.c testsuites/psxtests/psxhdrs/proc10.c testsuites/psxtests/psxhdrs/proc11.c testsuites/psxtests/psxhdrs/proc12.c testsuites/psxtests/psxhdrs/proc13.c testsuites/psxtests/psxhdrs/proc14.c testsuites/psxtests/psxhdrs/pthread01.c testsuites/psxtests/psxhdrs/pthread02.c testsuites/psxtests/psxhdrs/pthread03.c testsuites/psxtests/psxhdrs/pthread04.c testsuites/psxtests/psxhdrs/pthread05.c testsuites/psxtests/psxhdrs/pthread06.c testsuites/psxtests/psxhdrs/pthread07.c testsuites/psxtests/psxhdrs/pthread08.c testsuites/psxtests/psxhdrs/pthread09.c testsuites/psxtests/psxhdrs/pthread10.c testsuites/psxtests/psxhdrs/pthread11.c testsuites/psxtests/psxhdrs/pthread12.c testsuites/psxtests/psxhdrs/pthread13.c testsuites/psxtests/psxhdrs/pthread14.c testsuites/psxtests/psxhdrs/pthread15.c testsuites/psxtests/psxhdrs/pthread16.c testsuites/psxtests/psxhdrs/pthread17.c testsuites/psxtests/psxhdrs/pthread18.c testsuites/psxtests/psxhdrs/pthread19.c testsuites/psxtests/psxhdrs/pthread20.c testsuites/psxtests/psxhdrs/pthread21.c testsuites/psxtests/psxhdrs/pthread22.c testsuites/psxtests/psxhdrs/pthread23.c testsuites/psxtests/psxhdrs/pthread24.c testsuites/psxtests/psxhdrs/pthread25.c testsuites/psxtests/psxhdrs/pthread26.c testsuites/psxtests/psxhdrs/pthread27.c testsuites/psxtests/psxhdrs/pthread28.c testsuites/psxtests/psxhdrs/pthread29.c testsuites/psxtests/psxhdrs/pthread30.c testsuites/psxtests/psxhdrs/pthread31.c testsuites/psxtests/psxhdrs/pthread32.c testsuites/psxtests/psxhdrs/pthread33.c testsuites/psxtests/psxhdrs/pthread34.c testsuites/psxtests/psxhdrs/pthread35.c testsuites/psxtests/psxhdrs/pthread36.c testsuites/psxtests/psxhdrs/sched01.c testsuites/psxtests/psxhdrs/sched02.c testsuites/psxtests/psxhdrs/sched03.c testsuites/psxtests/psxhdrs/sched04.c testsuites/psxtests/psxhdrs/sched05.c testsuites/psxtests/psxhdrs/sched06.c testsuites/psxtests/psxhdrs/sched07.c testsuites/psxtests/psxhdrs/sched08.c testsuites/psxtests/psxhdrs/signal01.c testsuites/psxtests/psxhdrs/signal02.c testsuites/psxtests/psxhdrs/signal03.c testsuites/psxtests/psxhdrs/signal04.c testsuites/psxtests/psxhdrs/signal05.c testsuites/psxtests/psxhdrs/signal06.c testsuites/psxtests/psxhdrs/signal07.c testsuites/psxtests/psxhdrs/signal08.c testsuites/psxtests/psxhdrs/signal09.c testsuites/psxtests/psxhdrs/signal10.c testsuites/psxtests/psxhdrs/signal11.c testsuites/psxtests/psxhdrs/signal12.c testsuites/psxtests/psxhdrs/signal13.c testsuites/psxtests/psxhdrs/signal14.c testsuites/psxtests/psxhdrs/signal15.c testsuites/psxtests/psxhdrs/signal16.c testsuites/psxtests/psxhdrs/signal17.c testsuites/psxtests/psxhdrs/signal18.c testsuites/psxtests/psxhdrs/signal19.c testsuites/psxtests/psxhdrs/signal20.c testsuites/psxtests/psxhdrs/signal21.c testsuites/psxtests/psxhdrs/signal22.c testsuites/psxtests/psxhdrs/time01.c testsuites/psxtests/psxhdrs/time02.c testsuites/psxtests/psxhdrs/time03.c testsuites/psxtests/psxhdrs/time04.c testsuites/psxtests/psxhdrs/time05.c testsuites/psxtests/psxhdrs/time06.c testsuites/psxtests/psxhdrs/time07.c testsuites/psxtests/psxhdrs/time08.c testsuites/psxtests/psxhdrs/time09.c testsuites/psxtests/psxhdrs/time10.c testsuites/psxtests/psxhdrs/time11.c testsuites/psxtests/psxhdrs/time12.c testsuites/psxtests/psxhdrs/time13.c testsuites/psxtests/psxhdrs/timer01.c testsuites/psxtests/psxhdrs/timer02.c testsuites/psxtests/psxhdrs/timer03.c testsuites/psxtests/psxhdrs/timer04.c testsuites/psxtests/psxhdrs/timer05.c testsuites/psxtests/psxhdrs/timer06.c testsuites/samples/README testsuites/samples/base_mp/apptask.c testsuites/samples/base_mp/init.c testsuites/samples/base_mp/node1/base_mp.doc testsuites/samples/base_mp/node1/base_mp.scn testsuites/samples/base_mp/node2/base_mp.doc testsuites/samples/base_mp/node2/base_mp.scn testsuites/samples/base_mp/system.h testsuites/samples/base_sp/apptask.c testsuites/samples/base_sp/base_sp.doc testsuites/samples/base_sp/base_sp.scn testsuites/samples/base_sp/init.c testsuites/samples/base_sp/system.h testsuites/samples/cdtest/cdtest.scn testsuites/samples/cdtest/init.c testsuites/samples/cdtest/main.cc testsuites/samples/cdtest/system.h testsuites/samples/hello/hello.doc testsuites/samples/hello/hello.scn testsuites/samples/hello/init.c testsuites/samples/hello/system.h testsuites/samples/paranoia/init.c testsuites/samples/paranoia/paranoia.c testsuites/samples/paranoia/paranoia.doc testsuites/samples/paranoia/system.h testsuites/samples/ticker/init.c testsuites/samples/ticker/system.h testsuites/samples/ticker/tasks.c testsuites/samples/ticker/ticker.doc testsuites/samples/ticker/ticker.scn testsuites/sptests/README testsuites/sptests/sp01/init.c testsuites/sptests/sp01/sp01.doc testsuites/sptests/sp01/sp01.scn testsuites/sptests/sp01/system.h testsuites/sptests/sp01/task1.c testsuites/sptests/sp02/init.c testsuites/sptests/sp02/preempt.c testsuites/sptests/sp02/sp02.doc testsuites/sptests/sp02/sp02.scn testsuites/sptests/sp02/system.h testsuites/sptests/sp02/task1.c testsuites/sptests/sp02/task2.c testsuites/sptests/sp02/task3.c testsuites/sptests/sp03/init.c testsuites/sptests/sp03/sp03.doc testsuites/sptests/sp03/sp03.scn testsuites/sptests/sp03/system.h testsuites/sptests/sp03/task1.c testsuites/sptests/sp03/task2.c testsuites/sptests/sp04/init.c testsuites/sptests/sp04/sp04.doc testsuites/sptests/sp04/sp04.scn testsuites/sptests/sp04/system.h testsuites/sptests/sp04/task1.c testsuites/sptests/sp04/task2.c testsuites/sptests/sp04/task3.c testsuites/sptests/sp04/tswitch.c testsuites/sptests/sp05/init.c testsuites/sptests/sp05/sp05.doc testsuites/sptests/sp05/sp05.scn testsuites/sptests/sp05/system.h testsuites/sptests/sp05/task1.c testsuites/sptests/sp05/task2.c testsuites/sptests/sp05/task3.c testsuites/sptests/sp06/init.c testsuites/sptests/sp06/sp06.doc testsuites/sptests/sp06/sp06.scn testsuites/sptests/sp06/system.h testsuites/sptests/sp06/task1.c testsuites/sptests/sp06/task2.c testsuites/sptests/sp06/task3.c testsuites/sptests/sp07/init.c testsuites/sptests/sp07/sp07.doc testsuites/sptests/sp07/sp07.scn testsuites/sptests/sp07/system.h testsuites/sptests/sp07/task1.c testsuites/sptests/sp07/task2.c testsuites/sptests/sp07/task3.c testsuites/sptests/sp07/task4.c testsuites/sptests/sp07/taskexit.c testsuites/sptests/sp07/tcreate.c testsuites/sptests/sp07/tdelete.c testsuites/sptests/sp07/trestart.c testsuites/sptests/sp07/tstart.c testsuites/sptests/sp08/init.c testsuites/sptests/sp08/sp08.doc testsuites/sptests/sp08/sp08.scn testsuites/sptests/sp08/system.h testsuites/sptests/sp08/task1.c testsuites/sptests/sp09/delay.c testsuites/sptests/sp09/init.c testsuites/sptests/sp09/isr.c testsuites/sptests/sp09/screen01.c testsuites/sptests/sp09/screen02.c testsuites/sptests/sp09/screen03.c testsuites/sptests/sp09/screen04.c testsuites/sptests/sp09/screen05.c testsuites/sptests/sp09/screen06.c testsuites/sptests/sp09/screen07.c testsuites/sptests/sp09/screen08.c testsuites/sptests/sp09/screen09.c testsuites/sptests/sp09/screen10.c testsuites/sptests/sp09/screen11.c testsuites/sptests/sp09/screen12.c testsuites/sptests/sp09/screen13.c testsuites/sptests/sp09/screen14.c testsuites/sptests/sp09/sp09.doc testsuites/sptests/sp09/sp09.scn testsuites/sptests/sp09/system.h testsuites/sptests/sp09/task1.c testsuites/sptests/sp09/task2.c testsuites/sptests/sp09/task3.c testsuites/sptests/sp09/task4.c testsuites/sptests/sp11/init.c testsuites/sptests/sp11/sp11.doc testsuites/sptests/sp11/sp11.scn testsuites/sptests/sp11/system.h testsuites/sptests/sp11/task1.c testsuites/sptests/sp11/task2.c testsuites/sptests/sp11/timer.c testsuites/sptests/sp12/init.c testsuites/sptests/sp12/pridrv.c testsuites/sptests/sp12/pritask.c testsuites/sptests/sp12/sp12.doc testsuites/sptests/sp12/sp12.scn testsuites/sptests/sp12/system.h testsuites/sptests/sp12/task1.c testsuites/sptests/sp12/task2.c testsuites/sptests/sp12/task3.c testsuites/sptests/sp12/task4.c testsuites/sptests/sp12/task5.c testsuites/sptests/sp13/fillbuff.c testsuites/sptests/sp13/init.c testsuites/sptests/sp13/putbuff.c testsuites/sptests/sp13/sp13.doc testsuites/sptests/sp13/sp13.scn testsuites/sptests/sp13/system.h testsuites/sptests/sp13/task1.c testsuites/sptests/sp13/task2.c testsuites/sptests/sp13/task3.c testsuites/sptests/sp14/asr.c testsuites/sptests/sp14/init.c testsuites/sptests/sp14/sp14.doc testsuites/sptests/sp14/sp14.scn testsuites/sptests/sp14/system.h testsuites/sptests/sp14/task1.c testsuites/sptests/sp14/task2.c testsuites/sptests/sp15/init.c testsuites/sptests/sp15/sp15.doc testsuites/sptests/sp15/sp15.scn testsuites/sptests/sp15/system.h testsuites/sptests/sp15/task1.c testsuites/sptests/sp16/init.c testsuites/sptests/sp16/sp16.doc testsuites/sptests/sp16/sp16.scn testsuites/sptests/sp16/system.h testsuites/sptests/sp16/task1.c testsuites/sptests/sp16/task2.c testsuites/sptests/sp16/task3.c testsuites/sptests/sp16/task4.c testsuites/sptests/sp16/task5.c testsuites/sptests/sp17/asr.c testsuites/sptests/sp17/init.c testsuites/sptests/sp17/sp17.doc testsuites/sptests/sp17/sp17.scn testsuites/sptests/sp17/system.h testsuites/sptests/sp17/task1.c testsuites/sptests/sp17/task2.c testsuites/sptests/sp19/first.c testsuites/sptests/sp19/fptask.c testsuites/sptests/sp19/fptest.h testsuites/sptests/sp19/init.c testsuites/sptests/sp19/inttest.h testsuites/sptests/sp19/sp19.doc testsuites/sptests/sp19/sp19.scn testsuites/sptests/sp19/system.h testsuites/sptests/sp19/task1.c testsuites/sptests/sp20/getall.c testsuites/sptests/sp20/init.c testsuites/sptests/sp20/sp20.doc testsuites/sptests/sp20/sp20.scn testsuites/sptests/sp20/system.h testsuites/sptests/sp20/task1.c testsuites/sptests/sp21/init.c testsuites/sptests/sp21/sp21.doc testsuites/sptests/sp21/sp21.scn testsuites/sptests/sp21/system.h testsuites/sptests/sp21/task1.c testsuites/sptests/sp22/delay.c testsuites/sptests/sp22/init.c testsuites/sptests/sp22/prtime.c testsuites/sptests/sp22/sp22.doc testsuites/sptests/sp22/sp22.scn testsuites/sptests/sp22/system.h testsuites/sptests/sp22/task1.c testsuites/sptests/sp23/init.c testsuites/sptests/sp23/sp23.doc testsuites/sptests/sp23/sp23.scn testsuites/sptests/sp23/system.h testsuites/sptests/sp23/task1.c testsuites/sptests/sp24/init.c testsuites/sptests/sp24/resume.c testsuites/sptests/sp24/sp24.doc testsuites/sptests/sp24/sp24.scn testsuites/sptests/sp24/system.h testsuites/sptests/sp24/task1.c testsuites/sptests/sp25/init.c testsuites/sptests/sp25/sp25.doc testsuites/sptests/sp25/sp25.scn testsuites/sptests/sp25/system.h testsuites/sptests/sp25/task1.c testsuites/sptests/spfatal/fatal.c testsuites/sptests/spfatal/init.c testsuites/sptests/spfatal/puterr.c testsuites/sptests/spfatal/spfatal.doc testsuites/sptests/spfatal/spfatal.scn testsuites/sptests/spfatal/system.h testsuites/sptests/spfatal/task1.c testsuites/sptests/spsize/getint.c testsuites/sptests/spsize/init.c testsuites/sptests/spsize/size.c testsuites/sptests/spsize/system.h testsuites/support/include/tmacros.h testsuites/tmtests/README testsuites/tmtests/include/timesys.h testsuites/tmtests/tm01/system.h testsuites/tmtests/tm01/task1.c testsuites/tmtests/tm01/tm01.doc testsuites/tmtests/tm02/system.h testsuites/tmtests/tm02/task1.c testsuites/tmtests/tm02/tm02.doc testsuites/tmtests/tm03/system.h testsuites/tmtests/tm03/task1.c testsuites/tmtests/tm03/tm03.doc testsuites/tmtests/tm04/system.h testsuites/tmtests/tm04/task1.c testsuites/tmtests/tm04/tm04.doc testsuites/tmtests/tm05/system.h testsuites/tmtests/tm05/task1.c testsuites/tmtests/tm05/tm05.doc testsuites/tmtests/tm06/system.h testsuites/tmtests/tm06/task1.c testsuites/tmtests/tm06/tm06.doc testsuites/tmtests/tm07/system.h testsuites/tmtests/tm07/task1.c testsuites/tmtests/tm07/tm07.doc testsuites/tmtests/tm08/system.h testsuites/tmtests/tm08/task1.c testsuites/tmtests/tm08/tm08.doc testsuites/tmtests/tm09/system.h testsuites/tmtests/tm09/task1.c testsuites/tmtests/tm09/tm09.doc testsuites/tmtests/tm10/system.h testsuites/tmtests/tm10/task1.c testsuites/tmtests/tm10/tm10.doc testsuites/tmtests/tm11/system.h testsuites/tmtests/tm11/task1.c testsuites/tmtests/tm11/tm11.doc testsuites/tmtests/tm12/system.h testsuites/tmtests/tm12/task1.c testsuites/tmtests/tm12/tm12.doc testsuites/tmtests/tm13/system.h testsuites/tmtests/tm13/task1.c testsuites/tmtests/tm13/tm13.doc testsuites/tmtests/tm14/system.h testsuites/tmtests/tm14/task1.c testsuites/tmtests/tm14/tm14.doc testsuites/tmtests/tm15/system.h testsuites/tmtests/tm15/task1.c testsuites/tmtests/tm15/tm15.doc testsuites/tmtests/tm16/system.h testsuites/tmtests/tm16/task1.c testsuites/tmtests/tm16/tm16.doc testsuites/tmtests/tm17/system.h testsuites/tmtests/tm17/task1.c testsuites/tmtests/tm17/tm17.doc testsuites/tmtests/tm18/system.h testsuites/tmtests/tm18/task1.c testsuites/tmtests/tm18/tm18.doc testsuites/tmtests/tm19/system.h testsuites/tmtests/tm19/task1.c testsuites/tmtests/tm19/tm19.doc testsuites/tmtests/tm20/system.h testsuites/tmtests/tm20/task1.c testsuites/tmtests/tm20/tm20.doc testsuites/tmtests/tm21/system.h testsuites/tmtests/tm21/task1.c testsuites/tmtests/tm21/tm21.doc testsuites/tmtests/tm22/system.h testsuites/tmtests/tm22/task1.c testsuites/tmtests/tm22/tm22.doc testsuites/tmtests/tm23/system.h testsuites/tmtests/tm23/task1.c testsuites/tmtests/tm23/tm23.doc testsuites/tmtests/tm24/system.h testsuites/tmtests/tm24/task1.c testsuites/tmtests/tm24/tm24.doc testsuites/tmtests/tm25/system.h testsuites/tmtests/tm25/task1.c testsuites/tmtests/tm25/tm25.doc testsuites/tmtests/tm26/fptest.h testsuites/tmtests/tm26/system.h testsuites/tmtests/tm26/task1.c testsuites/tmtests/tm26/tm26.doc testsuites/tmtests/tm27/system.h testsuites/tmtests/tm27/task1.c testsuites/tmtests/tm27/tm27.doc testsuites/tmtests/tm28/system.h testsuites/tmtests/tm28/task1.c testsuites/tmtests/tm28/tm28.doc testsuites/tmtests/tm29/system.h testsuites/tmtests/tm29/task1.c testsuites/tmtests/tm29/tm29.doc testsuites/tmtests/tmck/system.h testsuites/tmtests/tmck/task1.c testsuites/tmtests/tmck/tmck.doc testsuites/tmtests/tmoverhd/dumrtems.h testsuites/tmtests/tmoverhd/empty.c testsuites/tmtests/tmoverhd/system.h testsuites/tmtests/tmoverhd/testtask.c testsuites/tmtests/tmoverhd/tmoverhd.doc tools/build/README tools/build/cklength.c tools/build/eolstrip.c tools/build/os/msdos/README tools/build/os/msdos/cklength.uue tools/build/os/msdos/fixtimer.c tools/build/os/msdos/fixtimer.uue tools/build/os/msdos/ifc.c tools/build/os/msdos/ifc_exe.uue tools/build/packhex.c tools/build/scripts/README tools/build/src/cklength.c tools/build/src/eolstrip.c tools/build/src/packhex.c tools/build/src/unhex.c tools/build/unhex.c tools/cpu/hppa1.1/genoffsets.c tools/cpu/unix/gensize.c tools/update/310_to_320_list tools/update/README
author: cvs2git <rtems-devel@rtems.org> 1996-09-30 20:15:02 +0000
committer: cvs2git <rtems-devel@rtems.org> 1996-09-30 20:15:02 +0000
commit: 43e1177def5a04b962b591496b2990e1c57ce63e (patch)
tree: fc1be17df72a87979f270adb59423ca71992b18b /cpukit/zlib
parent: fixed incorrect placement of CPU_STRUCTURE_ALIGNMENT macro. (diff)
download: rtems-43e1177def5a04b962b591496b2990e1c57ce63e.tar.bz2
3 files changed, 0 insertions, 2249 deletions
diff --git a/cpukit/zlib/doc/rfc1950.txt b/cpukit/zlib/doc/rfc1950.txt
deleted file mode 100644
index ce6428a0f2..0000000000
--- a/cpukit/zlib/doc/rfc1950.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Deutsch
-Request for Comments: 1950                           Aladdin Enterprises
-Category: Informational                                      J-L. Gailly
-                                                                Info-ZIP
-                                                                May 1996
-
-
-         ZLIB Compressed Data Format Specification version 3.3
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-IESG Note:
-
-   The IESG takes no position on the validity of any Intellectual
-   Property Rights statements contained in this document.
-
-Notices
-
-   Copyright (c) 1996 L. Peter Deutsch and Jean-Loup Gailly
-
-   Permission is granted to copy and distribute this document for any
-   purpose and without charge, including translations into other
-   languages and incorporation into compilations, provided that the
-   copyright notice and this notice are preserved, and that any
-   substantive changes or deletions from the original are clearly
-   marked.
-
-   A pointer to the latest version of this and related documentation in
-   HTML format can be found at the URL
-   <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>.
-
-Abstract
-
-   This specification defines a lossless compressed data format.  The
-   data can be produced or consumed, even for an arbitrarily long
-   sequentially presented input data stream, using only an a priori
-   bounded amount of intermediate storage.  The format presently uses
-   the DEFLATE compression method but can be easily extended to use
-   other compression methods.  It can be implemented readily in a manner
-   not covered by patents.  This specification also defines the ADLER-32
-   checksum (an extension and improvement of the Fletcher checksum),
-   used for detection of data corruption, and provides an algorithm for
-   computing it.
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 1]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-Table of Contents
-
-   1. Introduction ................................................... 2
-      1.1. Purpose ................................................... 2
-      1.2. Intended audience ......................................... 3
-      1.3. Scope ..................................................... 3
-      1.4. Compliance ................................................ 3
-      1.5.  Definitions of terms and conventions used ................ 3
-      1.6. Changes from previous versions ............................ 3
-   2. Detailed specification ......................................... 3
-      2.1. Overall conventions ....................................... 3
-      2.2. Data format ............................................... 4
-      2.3. Compliance ................................................ 7
-   3. References ..................................................... 7
-   4. Source code .................................................... 8
-   5. Security Considerations ........................................ 8
-   6. Acknowledgements ............................................... 8
-   7. Authors' Addresses ............................................. 8
-   8. Appendix: Rationale ............................................ 9
-   9. Appendix: Sample code ..........................................10
-
-1. Introduction
-
-   1.1. Purpose
-
-      The purpose of this specification is to define a lossless
-      compressed data format that:
-
-          * Is independent of CPU type, operating system, file system,
-            and character set, and hence can be used for interchange;
-
-          * Can be produced or consumed, even for an arbitrarily long
-            sequentially presented input data stream, using only an a
-            priori bounded amount of intermediate storage, and hence can
-            be used in data communications or similar structures such as
-            Unix filters;
-
-          * Can use a number of different compression methods;
-
-          * Can be implemented readily in a manner not covered by
-            patents, and hence can be practiced freely.
-
-      The data format defined by this specification does not attempt to
-      allow random access to compressed data.
-
-
-
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 2]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-   1.2. Intended audience
-
-      This specification is intended for use by implementors of software
-      to compress data into zlib format and/or decompress data from zlib
-      format.
-
-      The text of the specification assumes a basic background in
-      programming at the level of bits and other primitive data
-      representations.
-
-   1.3. Scope
-
-      The specification specifies a compressed data format that can be
-      used for in-memory compression of a sequence of arbitrary bytes.
-
-   1.4. Compliance
-
-      Unless otherwise indicated below, a compliant decompressor must be
-      able to accept and decompress any data set that conforms to all
-      the specifications presented here; a compliant compressor must
-      produce data sets that conform to all the specifications presented
-      here.
-
-   1.5.  Definitions of terms and conventions used
-
-      byte: 8 bits stored or transmitted as a unit (same as an octet).
-      (For this specification, a byte is exactly 8 bits, even on
-      machines which store a character on a number of bits different
-      from 8.) See below, for the numbering of bits within a byte.
-
-   1.6. Changes from previous versions
-
-      Version 3.1 was the first public release of this specification.
-      In version 3.2, some terminology was changed and the Adler-32
-      sample code was rewritten for clarity.  In version 3.3, the
-      support for a preset dictionary was introduced, and the
-      specification was converted to RFC style.
-
-2. Detailed specification
-
-   2.1. Overall conventions
-
-      In the diagrams below, a box like this:
-
-         +---+
-         |   | <-- the vertical bars might be missing
-         +---+
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 3]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-      represents one byte; a box like this:
-
-         +==============+
-         |              |
-         +==============+
-
-      represents a variable number of bytes.
-
-      Bytes stored within a computer do not have a "bit order", since
-      they are always treated as a unit.  However, a byte considered as
-      an integer between 0 and 255 does have a most- and least-
-      significant bit, and since we write numbers with the most-
-      significant digit on the left, we also write bytes with the most-
-      significant bit on the left.  In the diagrams below, we number the
-      bits of a byte so that bit 0 is the least-significant bit, i.e.,
-      the bits are numbered:
-
-         +--------+
-         |76543210|
-         +--------+
-
-      Within a computer, a number may occupy multiple bytes.  All
-      multi-byte numbers in the format described here are stored with
-      the MOST-significant byte first (at the lower memory address).
-      For example, the decimal number 520 is stored as:
-
-             0     1
-         +--------+--------+
-         |00000010|00001000|
-         +--------+--------+
-          ^        ^
-          |        |
-          |        + less significant byte = 8
-          + more significant byte = 2 x 256
-
-   2.2. Data format
-
-      A zlib stream has the following structure:
-
-           0   1
-         +---+---+
-         |CMF|FLG|   (more-->)
-         +---+---+
-
-
-
-
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 4]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-      (if FLG.FDICT set)
-
-           0   1   2   3
-         +---+---+---+---+
-         |     DICTID    |   (more-->)
-         +---+---+---+---+
-
-         +=====================+---+---+---+---+
-         |...compressed data...|    ADLER32    |
-         +=====================+---+---+---+---+
-
-      Any data which may appear after ADLER32 are not part of the zlib
-      stream.
-
-      CMF (Compression Method and flags)
-         This byte is divided into a 4-bit compression method and a 4-
-         bit information field depending on the compression method.
-
-            bits 0 to 3  CM     Compression method
-            bits 4 to 7  CINFO  Compression info
-
-      CM (Compression method)
-         This identifies the compression method used in the file. CM = 8
-         denotes the "deflate" compression method with a window size up
-         to 32K.  This is the method used by gzip and PNG (see
-         references [1] and [2] in Chapter 3, below, for the reference
-         documents).  CM = 15 is reserved.  It might be used in a future
-         version of this specification to indicate the presence of an
-         extra field before the compressed data.
-
-      CINFO (Compression info)
-         For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
-         size, minus eight (CINFO=7 indicates a 32K window size). Values
-         of CINFO above 7 are not allowed in this version of the
-         specification.  CINFO is not defined in this specification for
-         CM not equal to 8.
-
-      FLG (FLaGs)
-         This flag byte is divided as follows:
-
-            bits 0 to 4  FCHECK  (check bits for CMF and FLG)
-            bit  5       FDICT   (preset dictionary)
-            bits 6 to 7  FLEVEL  (compression level)
-
-         The FCHECK value must be such that CMF and FLG, when viewed as
-         a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG),
-         is a multiple of 31.
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 5]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-      FDICT (Preset dictionary)
-         If FDICT is set, a DICT dictionary identifier is present
-         immediately after the FLG byte. The dictionary is a sequence of
-         bytes which are initially fed to the compressor without
-         producing any compressed output. DICT is the Adler-32 checksum
-         of this sequence of bytes (see the definition of ADLER32
-         below).  The decompressor can use this identifier to determine
-         which dictionary has been used by the compressor.
-
-      FLEVEL (Compression level)
-         These flags are available for use by specific compression
-         methods.  The "deflate" method (CM = 8) sets these flags as
-         follows:
-
-            0 - compressor used fastest algorithm
-            1 - compressor used fast algorithm
-            2 - compressor used default algorithm
-            3 - compressor used maximum compression, slowest algorithm
-
-         The information in FLEVEL is not needed for decompression; it
-         is there to indicate if recompression might be worthwhile.
-
-      compressed data
-         For compression method 8, the compressed data is stored in the
-         deflate compressed data format as described in the document
-         "DEFLATE Compressed Data Format Specification" by L. Peter
-         Deutsch. (See reference [3] in Chapter 3, below)
-
-         Other compressed data formats are not specified in this version
-         of the zlib specification.
-
-      ADLER32 (Adler-32 checksum)
-         This contains a checksum value of the uncompressed data
-         (excluding any dictionary data) computed according to Adler-32
-         algorithm. This algorithm is a 32-bit extension and improvement
-         of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073
-         standard. See references [4] and [5] in Chapter 3, below)
-
-         Adler-32 is composed of two sums accumulated per byte: s1 is
-         the sum of all bytes, s2 is the sum of all s1 values. Both sums
-         are done modulo 65521. s1 is initialized to 1, s2 to zero.  The
-         Adler-32 checksum is stored as s2*65536 + s1 in most-
-         significant-byte first (network) order.
-
-
-
-
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 6]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-   2.3. Compliance
-
-      A compliant compressor must produce streams with correct CMF, FLG
-      and ADLER32, but need not support preset dictionaries.  When the
-      zlib data format is used as part of another standard data format,
-      the compressor may use only preset dictionaries that are specified
-      by this other data format.  If this other format does not use the
-      preset dictionary feature, the compressor must not set the FDICT
-      flag.
-
-      A compliant decompressor must check CMF, FLG, and ADLER32, and
-      provide an error indication if any of these have incorrect values.
-      A compliant decompressor must give an error indication if CM is
-      not one of the values defined in this specification (only the
-      value 8 is permitted in this version), since another value could
-      indicate the presence of new features that would cause subsequent
-      data to be interpreted incorrectly.  A compliant decompressor must
-      give an error indication if FDICT is set and DICTID is not the
-      identifier of a known preset dictionary.  A decompressor may
-      ignore FLEVEL and still be compliant.  When the zlib data format
-      is being used as a part of another standard format, a compliant
-      decompressor must support all the preset dictionaries specified by
-      the other format. When the other format does not use the preset
-      dictionary feature, a compliant decompressor must reject any
-      stream in which the FDICT flag is set.
-
-3. References
-
-   [1] Deutsch, L.P.,"GZIP Compressed Data Format Specification",
-       available in ftp://ftp.uu.net/pub/archiving/zip/doc/
-
-   [2] Thomas Boutell, "PNG (Portable Network Graphics) specification",
-       available in ftp://ftp.uu.net/graphics/png/documents/
-
-   [3] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
-       available in ftp://ftp.uu.net/pub/archiving/zip/doc/
-
-   [4] Fletcher, J. G., "An Arithmetic Checksum for Serial
-       Transmissions," IEEE Transactions on Communications, Vol. COM-30,
-       No. 1, January 1982, pp. 247-252.
-
-   [5] ITU-T Recommendation X.224, Annex D, "Checksum Algorithms,"
-       November, 1993, pp. 144, 145. (Available from
-       gopher://info.itu.ch). ITU-T X.244 is also the same as ISO 8073.
-
-
-
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 7]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-4. Source code
-
-   Source code for a C language implementation of a "zlib" compliant
-   library is available at ftp://ftp.uu.net/pub/archiving/zip/zlib/.
-
-5. Security Considerations
-
-   A decoder that fails to check the ADLER32 checksum value may be
-   subject to undetected data corruption.
-
-6. Acknowledgements
-
-   Trademarks cited in this document are the property of their
-   respective owners.
-
-   Jean-Loup Gailly and Mark Adler designed the zlib format and wrote
-   the related software described in this specification.  Glenn
-   Randers-Pehrson converted this document to RFC and HTML format.
-
-7. Authors' Addresses
-
-   L. Peter Deutsch
-   Aladdin Enterprises
-   203 Santa Margarita Ave.
-   Menlo Park, CA 94025
-
-   Phone: (415) 322-0103 (AM only)
-   FAX:   (415) 322-1734
-   EMail: <ghost@aladdin.com>
-
-
-   Jean-Loup Gailly
-
-   EMail: <gzip@prep.ai.mit.edu>
-
-   Questions about the technical content of this specification can be
-   sent by email to
-
-   Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
-   Mark Adler <madler@alumni.caltech.edu>
-
-   Editorial comments on this specification can be sent by email to
-
-   L. Peter Deutsch <ghost@aladdin.com> and
-   Glenn Randers-Pehrson <randeg@alumni.rpi.edu>
-
-
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 8]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-8. Appendix: Rationale
-
-   8.1. Preset dictionaries
-
-      A preset dictionary is specially useful to compress short input
-      sequences. The compressor can take advantage of the dictionary
-      context to encode the input in a more compact manner. The
-      decompressor can be initialized with the appropriate context by
-      virtually decompressing a compressed version of the dictionary
-      without producing any output. However for certain compression
-      algorithms such as the deflate algorithm this operation can be
-      achieved without actually performing any decompression.
-
-      The compressor and the decompressor must use exactly the same
-      dictionary. The dictionary may be fixed or may be chosen among a
-      certain number of predefined dictionaries, according to the kind
-      of input data. The decompressor can determine which dictionary has
-      been chosen by the compressor by checking the dictionary
-      identifier. This document does not specify the contents of
-      predefined dictionaries, since the optimal dictionaries are
-      application specific. Standard data formats using this feature of
-      the zlib specification must precisely define the allowed
-      dictionaries.
-
-   8.2. The Adler-32 algorithm
-
-      The Adler-32 algorithm is much faster than the CRC32 algorithm yet
-      still provides an extremely low probability of undetected errors.
-
-      The modulo on unsigned long accumulators can be delayed for 5552
-      bytes, so the modulo operation time is negligible.  If the bytes
-      are a, b, c, the second sum is 3a + 2b + c + 3, and so is position
-      and order sensitive, unlike the first sum, which is just a
-      checksum.  That 65521 is prime is important to avoid a possible
-      large class of two-byte errors that leave the check unchanged.
-      (The Fletcher checksum uses 255, which is not prime and which also
-      makes the Fletcher check insensitive to single byte changes 0 <->
-      255.)
-
-      The sum s1 is initialized to 1 instead of zero to make the length
-      of the sequence part of s2, so that the length does not have to be
-      checked separately. (Any sequence of zeroes has a Fletcher
-      checksum of zero.)
-
-
-
-
-
-
-
-
-Deutsch & Gailly             Informational                      [Page 9]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-9. Appendix: Sample code
-
-   The following C code computes the Adler-32 checksum of a data buffer.
-   It is written for clarity, not for speed.  The sample code is in the
-   ANSI C programming language. Non C users may find it easier to read
-   with these hints:
-
-      &      Bitwise AND operator.
-      >>     Bitwise right shift operator. When applied to an
-             unsigned quantity, as here, right shift inserts zero bit(s)
-             at the left.
-      <<     Bitwise left shift operator. Left shift inserts zero
-             bit(s) at the right.
-      ++     "n++" increments the variable n.
-      %      modulo operator: a % b is the remainder of a divided by b.
-
-      #define BASE 65521 /* largest prime smaller than 65536 */
-
-      /*
-         Update a running Adler-32 checksum with the bytes buf[0..len-1]
-       and return the updated checksum. The Adler-32 checksum should be
-       initialized to 1.
-
-       Usage example:
-
-         unsigned long adler = 1L;
-
-         while (read_buffer(buffer, length) != EOF) {
-           adler = update_adler32(adler, buffer, length);
-         }
-         if (adler != original_adler) error();
-      */
-      unsigned long update_adler32(unsigned long adler,
-         unsigned char *buf, int len)
-      {
-        unsigned long s1 = adler & 0xffff;
-        unsigned long s2 = (adler >> 16) & 0xffff;
-        int n;
-
-        for (n = 0; n < len; n++) {
-          s1 = (s1 + buf[n]) % BASE;
-          s2 = (s2 + s1)     % BASE;
-        }
-        return (s2 << 16) + s1;
-      }
-
-      /* Return the adler32 of the bytes buf[0..len-1] */
-
-
-
-
-Deutsch & Gailly             Informational                     [Page 10]
-
-RFC 1950       ZLIB Compressed Data Format Specification        May 1996
-
-
-      unsigned long adler32(unsigned char *buf, int len)
-      {
-        return update_adler32(1L, buf, len);
-      }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Deutsch & Gailly             Informational                     [Page 11]
-
diff --git a/cpukit/zlib/doc/rfc1951.txt b/cpukit/zlib/doc/rfc1951.txt
deleted file mode 100644
index 403c8c722f..0000000000
--- a/cpukit/zlib/doc/rfc1951.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Deutsch
-Request for Comments: 1951                           Aladdin Enterprises
-Category: Informational                                         May 1996
-
-
-        DEFLATE Compressed Data Format Specification version 1.3
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-IESG Note:
-
-   The IESG takes no position on the validity of any Intellectual
-   Property Rights statements contained in this document.
-
-Notices
-
-   Copyright (c) 1996 L. Peter Deutsch
-
-   Permission is granted to copy and distribute this document for any
-   purpose and without charge, including translations into other
-   languages and incorporation into compilations, provided that the
-   copyright notice and this notice are preserved, and that any
-   substantive changes or deletions from the original are clearly
-   marked.
-
-   A pointer to the latest version of this and related documentation in
-   HTML format can be found at the URL
-   <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>.
-
-Abstract
-
-   This specification defines a lossless compressed data format that
-   compresses data using a combination of the LZ77 algorithm and Huffman
-   coding, with efficiency comparable to the best currently available
-   general-purpose compression methods.  The data can be produced or
-   consumed, even for an arbitrarily long sequentially presented input
-   data stream, using only an a priori bounded amount of intermediate
-   storage.  The format can be implemented readily in a manner not
-   covered by patents.
-
-
-
-
-
-
-
-
-Deutsch                      Informational                      [Page 1]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-Table of Contents
-
-   1. Introduction ................................................... 2
-      1.1. Purpose ................................................... 2
-      1.2. Intended audience ......................................... 3
-      1.3. Scope ..................................................... 3
-      1.4. Compliance ................................................ 3
-      1.5.  Definitions of terms and conventions used ................ 3
-      1.6. Changes from previous versions ............................ 4
-   2. Compressed representation overview ............................. 4
-   3. Detailed specification ......................................... 5
-      3.1. Overall conventions ....................................... 5
-          3.1.1. Packing into bytes .................................. 5
-      3.2. Compressed block format ................................... 6
-          3.2.1. Synopsis of prefix and Huffman coding ............... 6
-          3.2.2. Use of Huffman coding in the "deflate" format ....... 7
-          3.2.3. Details of block format ............................. 9
-          3.2.4. Non-compressed blocks (BTYPE=00) ................... 11
-          3.2.5. Compressed blocks (length and distance codes) ...... 11
-          3.2.6. Compression with fixed Huffman codes (BTYPE=01) .... 12
-          3.2.7. Compression with dynamic Huffman codes (BTYPE=10) .. 13
-      3.3. Compliance ............................................... 14
-   4. Compression algorithm details ................................. 14
-   5. References .................................................... 16
-   6. Security Considerations ....................................... 16
-   7. Source code ................................................... 16
-   8. Acknowledgements .............................................. 16
-   9. Author's Address .............................................. 17
-
-1. Introduction
-
-   1.1. Purpose
-
-      The purpose of this specification is to define a lossless
-      compressed data format that:
-          * Is independent of CPU type, operating system, file system,
-            and character set, and hence can be used for interchange;
-          * Can be produced or consumed, even for an arbitrarily long
-            sequentially presented input data stream, using only an a
-            priori bounded amount of intermediate storage, and hence
-            can be used in data communications or similar structures
-            such as Unix filters;
-          * Compresses data with efficiency comparable to the best
-            currently available general-purpose compression methods,
-            and in particular considerably better than the "compress"
-            program;
-          * Can be implemented readily in a manner not covered by
-            patents, and hence can be practiced freely;
-
-
-
-Deutsch                      Informational                      [Page 2]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-          * Is compatible with the file format produced by the current
-            widely used gzip utility, in that conforming decompressors
-            will be able to read data produced by the existing gzip
-            compressor.
-
-      The data format defined by this specification does not attempt to:
-
-          * Allow random access to compressed data;
-          * Compress specialized data (e.g., raster graphics) as well
-            as the best currently available specialized algorithms.
-
-      A simple counting argument shows that no lossless compression
-      algorithm can compress every possible input data set.  For the
-      format defined here, the worst case expansion is 5 bytes per 32K-
-      byte block, i.e., a size increase of 0.015% for large data sets.
-      English text usually compresses by a factor of 2.5 to 3;
-      executable files usually compress somewhat less; graphical data
-      such as raster images may compress much more.
-
-   1.2. Intended audience
-
-      This specification is intended for use by implementors of software
-      to compress data into "deflate" format and/or decompress data from
-      "deflate" format.
-
-      The text of the specification assumes a basic background in
-      programming at the level of bits and other primitive data
-      representations.  Familiarity with the technique of Huffman coding
-      is helpful but not required.
-
-   1.3. Scope
-
-      The specification specifies a method for representing a sequence
-      of bytes as a (usually shorter) sequence of bits, and a method for
-      packing the latter bit sequence into bytes.
-
-   1.4. Compliance
-
-      Unless otherwise indicated below, a compliant decompressor must be
-      able to accept and decompress any data set that conforms to all
-      the specifications presented here; a compliant compressor must
-      produce data sets that conform to all the specifications presented
-      here.
-
-   1.5.  Definitions of terms and conventions used
-
-      Byte: 8 bits stored or transmitted as a unit (same as an octet).
-      For this specification, a byte is exactly 8 bits, even on machines
-
-
-
-Deutsch                      Informational                      [Page 3]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-      which store a character on a number of bits different from eight.
-      See below, for the numbering of bits within a byte.
-
-      String: a sequence of arbitrary bytes.
-
-   1.6. Changes from previous versions
-
-      There have been no technical changes to the deflate format since
-      version 1.1 of this specification.  In version 1.2, some
-      terminology was changed.  Version 1.3 is a conversion of the
-      specification to RFC style.
-
-2. Compressed representation overview
-
-   A compressed data set consists of a series of blocks, corresponding
-   to successive blocks of input data.  The block sizes are arbitrary,
-   except that non-compressible blocks are limited to 65,535 bytes.
-
-   Each block is compressed using a combination of the LZ77 algorithm
-   and Huffman coding. The Huffman trees for each block are independent
-   of those for previous or subsequent blocks; the LZ77 algorithm may
-   use a reference to a duplicated string occurring in a previous block,
-   up to 32K input bytes before.
-
-   Each block consists of two parts: a pair of Huffman code trees that
-   describe the representation of the compressed data part, and a
-   compressed data part.  (The Huffman trees themselves are compressed
-   using Huffman encoding.)  The compressed data consists of a series of
-   elements of two types: literal bytes (of strings that have not been
-   detected as duplicated within the previous 32K input bytes), and
-   pointers to duplicated strings, where a pointer is represented as a
-   pair <length, backward distance>.  The representation used in the
-   "deflate" format limits distances to 32K bytes and lengths to 258
-   bytes, but does not limit the size of a block, except for
-   uncompressible blocks, which are limited as noted above.
-
-   Each type of value (literals, distances, and lengths) in the
-   compressed data is represented using a Huffman code, using one code
-   tree for literals and lengths and a separate code tree for distances.
-   The code trees for each block appear in a compact form just before
-   the compressed data for that block.
-
-
-
-
-
-
-
-
-
-
-Deutsch                      Informational                      [Page 4]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-3. Detailed specification
-
-   3.1. Overall conventions In the diagrams below, a box like this:
-
-         +---+
-         |   | <-- the vertical bars might be missing
-         +---+
-
-      represents one byte; a box like this:
-
-         +==============+
-         |              |
-         +==============+
-
-      represents a variable number of bytes.
-
-      Bytes stored within a computer do not have a "bit order", since
-      they are always treated as a unit.  However, a byte considered as
-      an integer between 0 and 255 does have a most- and least-
-      significant bit, and since we write numbers with the most-
-      significant digit on the left, we also write bytes with the most-
-      significant bit on the left.  In the diagrams below, we number the
-      bits of a byte so that bit 0 is the least-significant bit, i.e.,
-      the bits are numbered:
-
-         +--------+
-         |76543210|
-         +--------+
-
-      Within a computer, a number may occupy multiple bytes.  All
-      multi-byte numbers in the format described here are stored with
-      the least-significant byte first (at the lower memory address).
-      For example, the decimal number 520 is stored as:
-
-             0        1
-         +--------+--------+
-         |00001000|00000010|
-         +--------+--------+
-          ^        ^
-          |        |
-          |        + more significant byte = 2 x 256
-          + less significant byte = 8
-
-      3.1.1. Packing into bytes
-
-         This document does not address the issue of the order in which
-         bits of a byte are transmitted on a bit-sequential medium,
-         since the final data format described here is byte- rather than
-
-
-
-Deutsch                      Informational                      [Page 5]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-         bit-oriented.  However, we describe the compressed block format
-         in below, as a sequence of data elements of various bit
-         lengths, not a sequence of bytes.  We must therefore specify
-         how to pack these data elements into bytes to form the final
-         compressed byte sequence:
-
-             * Data elements are packed into bytes in order of
-               increasing bit number within the byte, i.e., starting
-               with the least-significant bit of the byte.
-             * Data elements other than Huffman codes are packed
-               starting with the least-significant bit of the data
-               element.
-             * Huffman codes are packed starting with the most-
-               significant bit of the code.
-
-         In other words, if one were to print out the compressed data as
-         a sequence of bytes, starting with the first byte at the
-         *right* margin and proceeding to the *left*, with the most-
-         significant bit of each byte on the left as usual, one would be
-         able to parse the result from right to left, with fixed-width
-         elements in the correct MSB-to-LSB order and Huffman codes in
-         bit-reversed order (i.e., with the first bit of the code in the
-         relative LSB position).
-
-   3.2. Compressed block format
-
-      3.2.1. Synopsis of prefix and Huffman coding
-
-         Prefix coding represents symbols from an a priori known
-         alphabet by bit sequences (codes), one code for each symbol, in
-         a manner such that different symbols may be represented by bit
-         sequences of different lengths, but a parser can always parse
-         an encoded string unambiguously symbol-by-symbol.
-
-         We define a prefix code in terms of a binary tree in which the
-         two edges descending from each non-leaf node are labeled 0 and
-         1 and in which the leaf nodes correspond one-for-one with (are
-         labeled with) the symbols of the alphabet; then the code for a
-         symbol is the sequence of 0's and 1's on the edges leading from
-         the root to the leaf labeled with that symbol.  For example:
-
-
-
-
-
-
-
-
-
-
-
-Deutsch                      Informational                      [Page 6]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-                          /\              Symbol    Code
-                         0  1             ------    ----
-                        /    \                A      00
-                       /\     B               B       1
-                      0  1                    C     011
-                     /    \                   D     010
-                    A     /\
-                         0  1
-                        /    \
-                       D      C
-
-         A parser can decode the next symbol from an encoded input
-         stream by walking down the tree from the root, at each step
-         choosing the edge corresponding to the next input bit.
-
-         Given an alphabet with known symbol frequencies, the Huffman
-         algorithm allows the construction of an optimal prefix code
-         (one which represents strings with those symbol frequencies
-         using the fewest bits of any possible prefix codes for that
-         alphabet).  Such a code is called a Huffman code.  (See
-         reference [1] in Chapter 5, references for additional
-         information on Huffman codes.)
-
-         Note that in the "deflate" format, the Huffman codes for the
-         various alphabets must not exceed certain maximum code lengths.
-         This constraint complicates the algorithm for computing code
-         lengths from symbol frequencies.  Again, see Chapter 5,
-         references for details.
-
-      3.2.2. Use of Huffman coding in the "deflate" format
-
-         The Huffman codes used for each alphabet in the "deflate"
-         format have two additional rules:
-
-             * All codes of a given bit length have lexicographically
-               consecutive values, in the same order as the symbols
-               they represent;
-
-             * Shorter codes lexicographically precede longer codes.
-
-
-
-
-
-
-
-
-
-
-
-
-Deutsch                      Informational                      [Page 7]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-         We could recode the example above to follow this rule as
-         follows, assuming that the order of the alphabet is ABCD:
-
-            Symbol  Code
-            ------  ----
-            A       10
-            B       0
-            C       110
-            D       111
-
-         I.e., 0 precedes 10 which precedes 11x, and 110 and 111 are
-         lexicographically consecutive.
-
-         Given this rule, we can define the Huffman code for an alphabet
-         just by giving the bit lengths of the codes for each symbol of
-         the alphabet in order; this is sufficient to determine the
-         actual codes.  In our example, the code is completely defined
-         by the sequence of bit lengths (2, 1, 3, 3).  The following
-         algorithm generates the codes as integers, intended to be read
-         from most- to least-significant bit.  The code lengths are
-         initially in tree[I].Len; the codes are produced in
-         tree[I].Code.
-
-         1)  Count the number of codes for each code length.  Let
-             bl_count[N] be the number of codes of length N, N >= 1.
-
-         2)  Find the numerical value of the smallest code for each
-             code length:
-
-                code = 0;
-                bl_count[0] = 0;
-                for (bits = 1; bits <= MAX_BITS; bits++) {
-                    code = (code + bl_count[bits-1]) << 1;
-                    next_code[bits] = code;
-                }
-
-         3)  Assign numerical values to all codes, using consecutive
-             values for all codes of the same length with the base
-             values determined at step 2. Codes that are never used
-             (which have a bit length of zero) must not be assigned a
-             value.
-
-                for (n = 0;  n <= max_code; n++) {
-                    len = tree[n].Len;
-                    if (len != 0) {
-                        tree[n].Code = next_code[len];
-                        next_code[len]++;
-                    }
-
-
-
-Deutsch                      Informational                      [Page 8]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-                }
-
-         Example:
-
-         Consider the alphabet ABCDEFGH, with bit lengths (3, 3, 3, 3,
-         3, 2, 4, 4).  After step 1, we have:
-
-            N      bl_count[N]
-            -      -----------
-            2      1
-            3      5
-            4      2
-
-         Step 2 computes the following next_code values:
-
-            N      next_code[N]
-            -      ------------
-            1      0
-            2      0
-            3      2
-            4      14
-
-         Step 3 produces the following code values:
-
-            Symbol Length   Code
-            ------ ------   ----
-            A       3        010
-            B       3        011
-            C       3        100
-            D       3        101
-            E       3        110
-            F       2         00
-            G       4       1110
-            H       4       1111
-
-      3.2.3. Details of block format
-
-         Each block of compressed data begins with 3 header bits
-         containing the following data:
-
-            first bit       BFINAL
-            next 2 bits     BTYPE
-
-         Note that the header bits do not necessarily begin on a byte
-         boundary, since a block does not necessarily occupy an integral
-         number of bytes.
-
-
-
-
-
-Deutsch                      Informational                      [Page 9]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-         BFINAL is set if and only if this is the last block of the data
-         set.
-
-         BTYPE specifies how the data are compressed, as follows:
-
-            00 - no compression
-            01 - compressed with fixed Huffman codes
-            10 - compressed with dynamic Huffman codes
-            11 - reserved (error)
-
-         The only difference between the two compressed cases is how the
-         Huffman codes for the literal/length and distance alphabets are
-         defined.
-
-         In all cases, the decoding algorithm for the actual data is as
-         follows:
-
-            do
-               read block header from input stream.
-               if stored with no compression
-                  skip any remaining bits in current partially
-                     processed byte
-                  read LEN and NLEN (see next section)
-                  copy LEN bytes of data to output
-               otherwise
-                  if compressed with dynamic Huffman codes
-                     read representation of code trees (see
-                        subsection below)
-                  loop (until end of block code recognized)
-                     decode literal/length value from input stream
-                     if value < 256
-                        copy value (literal byte) to output stream
-                     otherwise
-                        if value = end of block (256)
-                           break from loop
-                        otherwise (value = 257..285)
-                           decode distance from input stream
-
-                           move backwards distance bytes in the output
-                           stream, and copy length bytes from this
-                           position to the output stream.
-                  end loop
-            while not last block
-
-         Note that a duplicated string reference may refer to a string
-         in a previous block; i.e., the backward distance may cross one
-         or more block boundaries.  However a distance cannot refer past
-         the beginning of the output stream.  (An application using a
-
-
-
-Deutsch                      Informational                     [Page 10]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-         preset dictionary might discard part of the output stream; a
-         distance can refer to that part of the output stream anyway)
-         Note also that the referenced string may overlap the current
-         position; for example, if the last 2 bytes decoded have values
-         X and Y, a string reference with <length = 5, distance = 2>
-         adds X,Y,X,Y,X to the output stream.
-
-         We now specify each compression method in turn.
-
-      3.2.4. Non-compressed blocks (BTYPE=00)
-
-         Any bits of input up to the next byte boundary are ignored.
-         The rest of the block consists of the following information:
-
-              0   1   2   3   4...
-            +---+---+---+---+================================+
-            |  LEN  | NLEN  |... LEN bytes of literal data...|
-            +---+---+---+---+================================+
-
-         LEN is the number of data bytes in the block.  NLEN is the
-         one's complement of LEN.
-
-      3.2.5. Compressed blocks (length and distance codes)
-
-         As noted above, encoded data blocks in the "deflate" format
-         consist of sequences of symbols drawn from three conceptually
-         distinct alphabets: either literal bytes, from the alphabet of
-         byte values (0..255), or <length, backward distance> pairs,
-         where the length is drawn from (3..258) and the distance is
-         drawn from (1..32,768).  In fact, the literal and length
-         alphabets are merged into a single alphabet (0..285), where
-         values 0..255 represent literal bytes, the value 256 indicates
-         end-of-block, and values 257..285 represent length codes
-         (possibly in conjunction with extra bits following the symbol
-         code) as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Deutsch                      Informational                     [Page 11]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-                 Extra               Extra               Extra
-            Code Bits Length(s) Code Bits Lengths   Code Bits Length(s)
-            ---- ---- ------     ---- ---- -------   ---- ---- -------
-             257   0     3       267   1   15,16     277   4   67-82
-             258   0     4       268   1   17,18     278   4   83-98
-             259   0     5       269   2   19-22     279   4   99-114
-             260   0     6       270   2   23-26     280   4  115-130
-             261   0     7       271   2   27-30     281   5  131-162
-             262   0     8       272   2   31-34     282   5  163-194
-             263   0     9       273   3   35-42     283   5  195-226
-             264   0    10       274   3   43-50     284   5  227-257
-             265   1  11,12      275   3   51-58     285   0    258
-             266   1  13,14      276   3   59-66
-
-         The extra bits should be interpreted as a machine integer
-         stored with the most-significant bit first, e.g., bits 1110
-         represent the value 14.
-
-                  Extra           Extra               Extra
-             Code Bits Dist  Code Bits   Dist     Code Bits Distance
-             ---- ---- ----  ---- ----  ------    ---- ---- --------
-               0   0    1     10   4     33-48    20    9   1025-1536
-               1   0    2     11   4     49-64    21    9   1537-2048
-               2   0    3     12   5     65-96    22   10   2049-3072
-               3   0    4     13   5     97-128   23   10   3073-4096
-               4   1   5,6    14   6    129-192   24   11   4097-6144
-               5   1   7,8    15   6    193-256   25   11   6145-8192
-               6   2   9-12   16   7    257-384   26   12  8193-12288
-               7   2  13-16   17   7    385-512   27   12 12289-16384
-               8   3  17-24   18   8    513-768   28   13 16385-24576
-               9   3  25-32   19   8   769-1024   29   13 24577-32768
-
-      3.2.6. Compression with fixed Huffman codes (BTYPE=01)
-
-         The Huffman codes for the two alphabets are fixed, and are not
-         represented explicitly in the data.  The Huffman code lengths
-         for the literal/length alphabet are:
-
-                   Lit Value    Bits        Codes
-                   ---------    ----        -----
-                     0 - 143     8          00110000 through
-                                            10111111
-                   144 - 255     9          110010000 through
-                                            111111111
-                   256 - 279     7          0000000 through
-                                            0010111
-                   280 - 287     8          11000000 through
-                                            11000111
-
-
-
-Deutsch                      Informational                     [Page 12]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-         The code lengths are sufficient to generate the actual codes,
-         as described above; we show the codes in the table for added
-         clarity.  Literal/length values 286-287 will never actually
-         occur in the compressed data, but participate in the code
-         construction.
-
-         Distance codes 0-31 are represented by (fixed-length) 5-bit
-         codes, with possible additional bits as shown in the table
-         shown in Paragraph 3.2.5, above.  Note that distance codes 30-
-         31 will never actually occur in the compressed data.
-
-      3.2.7. Compression with dynamic Huffman codes (BTYPE=10)
-
-         The Huffman codes for the two alphabets appear in the block
-         immediately after the header bits and before the actual
-         compressed data, first the literal/length code and then the
-         distance code.  Each code is defined by a sequence of code
-         lengths, as discussed in Paragraph 3.2.2, above.  For even
-         greater compactness, the code length sequences themselves are
-         compressed using a Huffman code.  The alphabet for code lengths
-         is as follows:
-
-               0 - 15: Represent code lengths of 0 - 15
-                   16: Copy the previous code length 3 - 6 times.
-                       The next 2 bits indicate repeat length
-                             (0 = 3, ... , 3 = 6)
-                          Example:  Codes 8, 16 (+2 bits 11),
-                                    16 (+2 bits 10) will expand to
-                                    12 code lengths of 8 (1 + 6 + 5)
-                   17: Repeat a code length of 0 for 3 - 10 times.
-                       (3 bits of length)
-                   18: Repeat a code length of 0 for 11 - 138 times
-                       (7 bits of length)
-
-         A code length of 0 indicates that the corresponding symbol in
-         the literal/length or distance alphabet will not occur in the
-         block, and should not participate in the Huffman code
-         construction algorithm given earlier.  If only one distance
-         code is used, it is encoded using one bit, not zero bits; in
-         this case there is a single code length of one, with one unused
-         code.  One distance code of zero bits means that there are no
-         distance codes used at all (the data is all literals).
-
-         We can now define the format of the block:
-
-               5 Bits: HLIT, # of Literal/Length codes - 257 (257 - 286)
-               5 Bits: HDIST, # of Distance codes - 1        (1 - 32)
-               4 Bits: HCLEN, # of Code Length codes - 4     (4 - 19)
-
-
-
-Deutsch                      Informational                     [Page 13]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-               (HCLEN + 4) x 3 bits: code lengths for the code length
-                  alphabet given just above, in the order: 16, 17, 18,
-                  0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
-
-                  These code lengths are interpreted as 3-bit integers
-                  (0-7); as above, a code length of 0 means the
-                  corresponding symbol (literal/length or distance code
-                  length) is not used.
-
-               HLIT + 257 code lengths for the literal/length alphabet,
-                  encoded using the code length Huffman code
-
-               HDIST + 1 code lengths for the distance alphabet,
-                  encoded using the code length Huffman code
-
-               The actual compressed data of the block,
-                  encoded using the literal/length and distance Huffman
-                  codes
-
-               The literal/length symbol 256 (end of data),
-                  encoded using the literal/length Huffman code
-
-         The code length repeat codes can cross from HLIT + 257 to the
-         HDIST + 1 code lengths.  In other words, all code lengths form
-         a single sequence of HLIT + HDIST + 258 values.
-
-   3.3. Compliance
-
-      A compressor may limit further the ranges of values specified in
-      the previous section and still be compliant; for example, it may
-      limit the range of backward pointers to some value smaller than
-      32K.  Similarly, a compressor may limit the size of blocks so that
-      a compressible block fits in memory.
-
-      A compliant decompressor must accept the full range of possible
-      values defined in the previous section, and must accept blocks of
-      arbitrary size.
-
-4. Compression algorithm details
-
-   While it is the intent of this document to define the "deflate"
-   compressed data format without reference to any particular
-   compression algorithm, the format is related to the compressed
-   formats produced by LZ77 (Lempel-Ziv 1977, see reference [2] below);
-   since many variations of LZ77 are patented, it is strongly
-   recommended that the implementor of a compressor follow the general
-   algorithm presented here, which is known not to be patented per se.
-   The material in this section is not part of the definition of the
-
-
-
-Deutsch                      Informational                     [Page 14]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-   specification per se, and a compressor need not follow it in order to
-   be compliant.
-
-   The compressor terminates a block when it determines that starting a
-   new block with fresh trees would be useful, or when the block size
-   fills up the compressor's block buffer.
-
-   The compressor uses a chained hash table to find duplicated strings,
-   using a hash function that operates on 3-byte sequences.  At any
-   given point during compression, let XYZ be the next 3 input bytes to
-   be examined (not necessarily all different, of course).  First, the
-   compressor examines the hash chain for XYZ.  If the chain is empty,
-   the compressor simply writes out X as a literal byte and advances one
-   byte in the input.  If the hash chain is not empty, indicating that
-   the sequence XYZ (or, if we are unlucky, some other 3 bytes with the
-   same hash function value) has occurred recently, the compressor
-   compares all strings on the XYZ hash chain with the actual input data
-   sequence starting at the current point, and selects the longest
-   match.
-
-   The compressor searches the hash chains starting with the most recent
-   strings, to favor small distances and thus take advantage of the
-   Huffman encoding.  The hash chains are singly linked. There are no
-   deletions from the hash chains; the algorithm simply discards matches
-   that are too old.  To avoid a worst-case situation, very long hash
-   chains are arbitrarily truncated at a certain length, determined by a
-   run-time parameter.
-
-   To improve overall compression, the compressor optionally defers the
-   selection of matches ("lazy matching"): after a match of length N has
-   been found, the compressor searches for a longer match starting at
-   the next input byte.  If it finds a longer match, it truncates the
-   previous match to a length of one (thus producing a single literal
-   byte) and then emits the longer match.  Otherwise, it emits the
-   original match, and, as described above, advances N bytes before
-   continuing.
-
-   Run-time parameters also control this "lazy match" procedure.  If
-   compression ratio is most important, the compressor attempts a
-   complete second search regardless of the length of the first match.
-   In the normal case, if the current match is "long enough", the
-   compressor reduces the search for a longer match, thus speeding up
-   the process.  If speed is most important, the compressor inserts new
-   strings in the hash table only when no match was found, or when the
-   match is not "too long".  This degrades the compression ratio but
-   saves time since there are both fewer insertions and fewer searches.
-
-
-
-
-
-Deutsch                      Informational                     [Page 15]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-5. References
-
-   [1] Huffman, D. A., "A Method for the Construction of Minimum
-       Redundancy Codes", Proceedings of the Institute of Radio
-       Engineers, September 1952, Volume 40, Number 9, pp. 1098-1101.
-
-   [2] Ziv J., Lempel A., "A Universal Algorithm for Sequential Data
-       Compression", IEEE Transactions on Information Theory, Vol. 23,
-       No. 3, pp. 337-343.
-
-   [3] Gailly, J.-L., and Adler, M., ZLIB documentation and sources,
-       available in ftp://ftp.uu.net/pub/archiving/zip/doc/
-
-   [4] Gailly, J.-L., and Adler, M., GZIP documentation and sources,
-       available as gzip-*.tar in ftp://prep.ai.mit.edu/pub/gnu/
-
-   [5] Schwartz, E. S., and Kallick, B. "Generating a canonical prefix
-       encoding." Comm. ACM, 7,3 (Mar. 1964), pp. 166-169.
-
-   [6] Hirschberg and Lelewer, "Efficient decoding of prefix codes,"
-       Comm. ACM, 33,4, April 1990, pp. 449-459.
-
-6. Security Considerations
-
-   Any data compression method involves the reduction of redundancy in
-   the data.  Consequently, any corruption of the data is likely to have
-   severe effects and be difficult to correct.  Uncompressed text, on
-   the other hand, will probably still be readable despite the presence
-   of some corrupted bytes.
-
-   It is recommended that systems using this data format provide some
-   means of validating the integrity of the compressed data.  See
-   reference [3], for example.
-
-7. Source code
-
-   Source code for a C language implementation of a "deflate" compliant
-   compressor and decompressor is available within the zlib package at
-   ftp://ftp.uu.net/pub/archiving/zip/zlib/.
-
-8. Acknowledgements
-
-   Trademarks cited in this document are the property of their
-   respective owners.
-
-   Phil Katz designed the deflate format.  Jean-Loup Gailly and Mark
-   Adler wrote the related software described in this specification.
-   Glenn Randers-Pehrson converted this document to RFC and HTML format.
-
-
-
-Deutsch                      Informational                     [Page 16]
-
-RFC 1951      DEFLATE Compressed Data Format Specification      May 1996
-
-
-9. Author's Address
-
-   L. Peter Deutsch
-   Aladdin Enterprises
-   203 Santa Margarita Ave.
-   Menlo Park, CA 94025
-
-   Phone: (415) 322-0103 (AM only)
-   FAX:   (415) 322-1734
-   EMail: <ghost@aladdin.com>
-
-   Questions about the technical content of this specification can be
-   sent by email to:
-
-   Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
-   Mark Adler <madler@alumni.caltech.edu>
-
-   Editorial comments on this specification can be sent by email to:
-
-   L. Peter Deutsch <ghost@aladdin.com> and
-   Glenn Randers-Pehrson <randeg@alumni.rpi.edu>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Deutsch                      Informational                     [Page 17]
-
diff --git a/cpukit/zlib/doc/rfc1952.txt b/cpukit/zlib/doc/rfc1952.txt
deleted file mode 100644
index a8e51b4567..0000000000
--- a/cpukit/zlib/doc/rfc1952.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Deutsch
-Request for Comments: 1952                           Aladdin Enterprises
-Category: Informational                                         May 1996
-
-
-               GZIP file format specification version 4.3
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-IESG Note:
-
-   The IESG takes no position on the validity of any Intellectual
-   Property Rights statements contained in this document.
-
-Notices
-
-   Copyright (c) 1996 L. Peter Deutsch
-
-   Permission is granted to copy and distribute this document for any
-   purpose and without charge, including translations into other
-   languages and incorporation into compilations, provided that the
-   copyright notice and this notice are preserved, and that any
-   substantive changes or deletions from the original are clearly
-   marked.
-
-   A pointer to the latest version of this and related documentation in
-   HTML format can be found at the URL
-   <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>.
-
-Abstract
-
-   This specification defines a lossless compressed data format that is
-   compatible with the widely used GZIP utility.  The format includes a
-   cyclic redundancy check value for detecting data corruption.  The
-   format presently uses the DEFLATE method of compression but can be
-   easily extended to use other compression methods.  The format can be
-   implemented readily in a manner not covered by patents.
-
-
-
-
-
-
-
-
-
-
-Deutsch                      Informational                      [Page 1]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-Table of Contents
-
-   1. Introduction ................................................... 2
-      1.1. Purpose ................................................... 2
-      1.2. Intended audience ......................................... 3
-      1.3. Scope ..................................................... 3
-      1.4. Compliance ................................................ 3
-      1.5. Definitions of terms and conventions used ................. 3
-      1.6. Changes from previous versions ............................ 3
-   2. Detailed specification ......................................... 4
-      2.1. Overall conventions ....................................... 4
-      2.2. File format ............................................... 5
-      2.3. Member format ............................................. 5
-          2.3.1. Member header and trailer ........................... 6
-              2.3.1.1. Extra field ................................... 8
-              2.3.1.2. Compliance .................................... 9
-      3. References .................................................. 9
-      4. Security Considerations .................................... 10
-      5. Acknowledgements ........................................... 10
-      6. Author's Address ........................................... 10
-      7. Appendix: Jean-Loup Gailly's gzip utility .................. 11
-      8. Appendix: Sample CRC Code .................................. 11
-
-1. Introduction
-
-   1.1. Purpose
-
-      The purpose of this specification is to define a lossless
-      compressed data format that:
-
-          * Is independent of CPU type, operating system, file system,
-            and character set, and hence can be used for interchange;
-          * Can compress or decompress a data stream (as opposed to a
-            randomly accessible file) to produce another data stream,
-            using only an a priori bounded amount of intermediate
-            storage, and hence can be used in data communications or
-            similar structures such as Unix filters;
-          * Compresses data with efficiency comparable to the best
-            currently available general-purpose compression methods,
-            and in particular considerably better than the "compress"
-            program;
-          * Can be implemented readily in a manner not covered by
-            patents, and hence can be practiced freely;
-          * Is compatible with the file format produced by the current
-            widely used gzip utility, in that conforming decompressors
-            will be able to read data produced by the existing gzip
-            compressor.
-
-
-
-
-Deutsch                      Informational                      [Page 2]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-      The data format defined by this specification does not attempt to:
-
-          * Provide random access to compressed data;
-          * Compress specialized data (e.g., raster graphics) as well as
-            the best currently available specialized algorithms.
-
-   1.2. Intended audience
-
-      This specification is intended for use by implementors of software
-      to compress data into gzip format and/or decompress data from gzip
-      format.
-
-      The text of the specification assumes a basic background in
-      programming at the level of bits and other primitive data
-      representations.
-
-   1.3. Scope
-
-      The specification specifies a compression method and a file format
-      (the latter assuming only that a file can store a sequence of
-      arbitrary bytes).  It does not specify any particular interface to
-      a file system or anything about character sets or encodings
-      (except for file names and comments, which are optional).
-
-   1.4. Compliance
-
-      Unless otherwise indicated below, a compliant decompressor must be
-      able to accept and decompress any file that conforms to all the
-      specifications presented here; a compliant compressor must produce
-      files that conform to all the specifications presented here.  The
-      material in the appendices is not part of the specification per se
-      and is not relevant to compliance.
-
-   1.5. Definitions of terms and conventions used
-
-      byte: 8 bits stored or transmitted as a unit (same as an octet).
-      (For this specification, a byte is exactly 8 bits, even on
-      machines which store a character on a number of bits different
-      from 8.)  See below for the numbering of bits within a byte.
-
-   1.6. Changes from previous versions
-
-      There have been no technical changes to the gzip format since
-      version 4.1 of this specification.  In version 4.2, some
-      terminology was changed, and the sample CRC code was rewritten for
-      clarity and to eliminate the requirement for the caller to do pre-
-      and post-conditioning.  Version 4.3 is a conversion of the
-      specification to RFC style.
-
-
-
-Deutsch                      Informational                      [Page 3]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-2. Detailed specification
-
-   2.1. Overall conventions
-
-      In the diagrams below, a box like this:
-
-         +---+
-         |   | <-- the vertical bars might be missing
-         +---+
-
-      represents one byte; a box like this:
-
-         +==============+
-         |              |
-         +==============+
-
-      represents a variable number of bytes.
-
-      Bytes stored within a computer do not have a "bit order", since
-      they are always treated as a unit.  However, a byte considered as
-      an integer between 0 and 255 does have a most- and least-
-      significant bit, and since we write numbers with the most-
-      significant digit on the left, we also write bytes with the most-
-      significant bit on the left.  In the diagrams below, we number the
-      bits of a byte so that bit 0 is the least-significant bit, i.e.,
-      the bits are numbered:
-
-         +--------+
-         |76543210|
-         +--------+
-
-      This document does not address the issue of the order in which
-      bits of a byte are transmitted on a bit-sequential medium, since
-      the data format described here is byte- rather than bit-oriented.
-
-      Within a computer, a number may occupy multiple bytes.  All
-      multi-byte numbers in the format described here are stored with
-      the least-significant byte first (at the lower memory address).
-      For example, the decimal number 520 is stored as:
-
-             0        1
-         +--------+--------+
-         |00001000|00000010|
-         +--------+--------+
-          ^        ^
-          |        |
-          |        + more significant byte = 2 x 256
-          + less significant byte = 8
-
-
-
-Deutsch                      Informational                      [Page 4]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-   2.2. File format
-
-      A gzip file consists of a series of "members" (compressed data
-      sets).  The format of each member is specified in the following
-      section.  The members simply appear one after another in the file,
-      with no additional information before, between, or after them.
-
-   2.3. Member format
-
-      Each member has the following structure:
-
-         +---+---+---+---+---+---+---+---+---+---+
-         |ID1|ID2|CM |FLG|     MTIME     |XFL|OS | (more-->)
-         +---+---+---+---+---+---+---+---+---+---+
-
-      (if FLG.FEXTRA set)
-
-         +---+---+=================================+
-         | XLEN  |...XLEN bytes of "extra field"...| (more-->)
-         +---+---+=================================+
-
-      (if FLG.FNAME set)
-
-         +=========================================+
-         |...original file name, zero-terminated...| (more-->)
-         +=========================================+
-
-      (if FLG.FCOMMENT set)
-
-         +===================================+
-         |...file comment, zero-terminated...| (more-->)
-         +===================================+
-
-      (if FLG.FHCRC set)
-
-         +---+---+
-         | CRC16 |
-         +---+---+
-
-         +=======================+
-         |...compressed blocks...| (more-->)
-         +=======================+
-
-           0   1   2   3   4   5   6   7
-         +---+---+---+---+---+---+---+---+
-         |     CRC32     |     ISIZE     |
-         +---+---+---+---+---+---+---+---+
-
-
-
-
-Deutsch                      Informational                      [Page 5]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-      2.3.1. Member header and trailer
-
-         ID1 (IDentification 1)
-         ID2 (IDentification 2)
-            These have the fixed values ID1 = 31 (0x1f, \037), ID2 = 139
-            (0x8b, \213), to identify the file as being in gzip format.
-
-         CM (Compression Method)
-            This identifies the compression method used in the file.  CM
-            = 0-7 are reserved.  CM = 8 denotes the "deflate"
-            compression method, which is the one customarily used by
-            gzip and which is documented elsewhere.
-
-         FLG (FLaGs)
-            This flag byte is divided into individual bits as follows:
-
-               bit 0   FTEXT
-               bit 1   FHCRC
-               bit 2   FEXTRA
-               bit 3   FNAME
-               bit 4   FCOMMENT
-               bit 5   reserved
-               bit 6   reserved
-               bit 7   reserved
-
-            If FTEXT is set, the file is probably ASCII text.  This is
-            an optional indication, which the compressor may set by
-            checking a small amount of the input data to see whether any
-            non-ASCII characters are present.  In case of doubt, FTEXT
-            is cleared, indicating binary data. For systems which have
-            different file formats for ascii text and binary data, the
-            decompressor can use FTEXT to choose the appropriate format.
-            We deliberately do not specify the algorithm used to set
-            this bit, since a compressor always has the option of
-            leaving it cleared and a decompressor always has the option
-            of ignoring it and letting some other program handle issues
-            of data conversion.
-
-            If FHCRC is set, a CRC16 for the gzip header is present,
-            immediately before the compressed data. The CRC16 consists
-            of the two least significant bytes of the CRC32 for all
-            bytes of the gzip header up to and not including the CRC16.
-            [The FHCRC bit was never set by versions of gzip up to
-            1.2.4, even though it was documented with a different
-            meaning in gzip 1.2.4.]
-
-            If FEXTRA is set, optional extra fields are present, as
-            described in a following section.
-
-
-
-Deutsch                      Informational                      [Page 6]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-            If FNAME is set, an original file name is present,
-            terminated by a zero byte.  The name must consist of ISO
-            8859-1 (LATIN-1) characters; on operating systems using
-            EBCDIC or any other character set for file names, the name
-            must be translated to the ISO LATIN-1 character set.  This
-            is the original name of the file being compressed, with any
-            directory components removed, and, if the file being
-            compressed is on a file system with case insensitive names,
-            forced to lower case. There is no original file name if the
-            data was compressed from a source other than a named file;
-            for example, if the source was stdin on a Unix system, there
-            is no file name.
-
-            If FCOMMENT is set, a zero-terminated file comment is
-            present.  This comment is not interpreted; it is only
-            intended for human consumption.  The comment must consist of
-            ISO 8859-1 (LATIN-1) characters.  Line breaks should be
-            denoted by a single line feed character (10 decimal).
-
-            Reserved FLG bits must be zero.
-
-         MTIME (Modification TIME)
-            This gives the most recent modification time of the original
-            file being compressed.  The time is in Unix format, i.e.,
-            seconds since 00:00:00 GMT, Jan.  1, 1970.  (Note that this
-            may cause problems for MS-DOS and other systems that use
-            local rather than Universal time.)  If the compressed data
-            did not come from a file, MTIME is set to the time at which
-            compression started.  MTIME = 0 means no time stamp is
-            available.
-
-         XFL (eXtra FLags)
-            These flags are available for use by specific compression
-            methods.  The "deflate" method (CM = 8) sets these flags as
-            follows:
-
-               XFL = 2 - compressor used maximum compression,
-                         slowest algorithm
-               XFL = 4 - compressor used fastest algorithm
-
-         OS (Operating System)
-            This identifies the type of file system on which compression
-            took place.  This may be useful in determining end-of-line
-            convention for text files.  The currently defined values are
-            as follows:
-
-
-
-
-
-
-Deutsch                      Informational                      [Page 7]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-                 0 - FAT filesystem (MS-DOS, OS/2, NT/Win32)
-                 1 - Amiga
-                 2 - VMS (or OpenVMS)
-                 3 - Unix
-                 4 - VM/CMS
-                 5 - Atari TOS
-                 6 - HPFS filesystem (OS/2, NT)
-                 7 - Macintosh
-                 8 - Z-System
-                 9 - CP/M
-                10 - TOPS-20
-                11 - NTFS filesystem (NT)
-                12 - QDOS
-                13 - Acorn RISCOS
-               255 - unknown
-
-         XLEN (eXtra LENgth)
-            If FLG.FEXTRA is set, this gives the length of the optional
-            extra field.  See below for details.
-
-         CRC32 (CRC-32)
-            This contains a Cyclic Redundancy Check value of the
-            uncompressed data computed according to CRC-32 algorithm
-            used in the ISO 3309 standard and in section 8.1.1.6.2 of
-            ITU-T recommendation V.42.  (See http://www.iso.ch for
-            ordering ISO documents. See gopher://info.itu.ch for an
-            online version of ITU-T V.42.)
-
-         ISIZE (Input SIZE)
-            This contains the size of the original (uncompressed) input
-            data modulo 2^32.
-
-      2.3.1.1. Extra field
-
-         If the FLG.FEXTRA bit is set, an "extra field" is present in
-         the header, with total length XLEN bytes.  It consists of a
-         series of subfields, each of the form:
-
-            +---+---+---+---+==================================+
-            |SI1|SI2|  LEN  |... LEN bytes of subfield data ...|
-            +---+---+---+---+==================================+
-
-         SI1 and SI2 provide a subfield ID, typically two ASCII letters
-         with some mnemonic value.  Jean-Loup Gailly
-         <gzip@prep.ai.mit.edu> is maintaining a registry of subfield
-         IDs; please send him any subfield ID you wish to use.  Subfield
-         IDs with SI2 = 0 are reserved for future use.  The following
-         IDs are currently defined:
-
-
-
-Deutsch                      Informational                      [Page 8]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-            SI1         SI2         Data
-            ----------  ----------  ----
-            0x41 ('A')  0x70 ('P')  Apollo file type information
-
-         LEN gives the length of the subfield data, excluding the 4
-         initial bytes.
-
-      2.3.1.2. Compliance
-
-         A compliant compressor must produce files with correct ID1,
-         ID2, CM, CRC32, and ISIZE, but may set all the other fields in
-         the fixed-length part of the header to default values (255 for
-         OS, 0 for all others).  The compressor must set all reserved
-         bits to zero.
-
-         A compliant decompressor must check ID1, ID2, and CM, and
-         provide an error indication if any of these have incorrect
-         values.  It must examine FEXTRA/XLEN, FNAME, FCOMMENT and FHCRC
-         at least so it can skip over the optional fields if they are
-         present.  It need not examine any other part of the header or
-         trailer; in particular, a decompressor may ignore FTEXT and OS
-         and always produce binary output, and still be compliant.  A
-         compliant decompressor must give an error indication if any
-         reserved bit is non-zero, since such a bit could indicate the
-         presence of a new field that would cause subsequent data to be
-         interpreted incorrectly.
-
-3. References
-
-   [1] "Information Processing - 8-bit single-byte coded graphic
-       character sets - Part 1: Latin alphabet No.1" (ISO 8859-1:1987).
-       The ISO 8859-1 (Latin-1) character set is a superset of 7-bit
-       ASCII. Files defining this character set are available as
-       iso_8859-1.* in ftp://ftp.uu.net/graphics/png/documents/
-
-   [2] ISO 3309
-
-   [3] ITU-T recommendation V.42
-
-   [4] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
-       available in ftp://ftp.uu.net/pub/archiving/zip/doc/
-
-   [5] Gailly, J.-L., GZIP documentation, available as gzip-*.tar in
-       ftp://prep.ai.mit.edu/pub/gnu/
-
-   [6] Sarwate, D.V., "Computation of Cyclic Redundancy Checks via Table
-       Look-Up", Communications of the ACM, 31(8), pp.1008-1013.
-
-
-
-
-Deutsch                      Informational                      [Page 9]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-   [7] Schwaderer, W.D., "CRC Calculation", April 85 PC Tech Journal,
-       pp.118-133.
-
-   [8] ftp://ftp.adelaide.edu.au/pub/rocksoft/papers/crc_v3.txt,
-       describing the CRC concept.
-
-4. Security Considerations
-
-   Any data compression method involves the reduction of redundancy in
-   the data.  Consequently, any corruption of the data is likely to have
-   severe effects and be difficult to correct.  Uncompressed text, on
-   the other hand, will probably still be readable despite the presence
-   of some corrupted bytes.
-
-   It is recommended that systems using this data format provide some
-   means of validating the integrity of the compressed data, such as by
-   setting and checking the CRC-32 check value.
-
-5. Acknowledgements
-
-   Trademarks cited in this document are the property of their
-   respective owners.
-
-   Jean-Loup Gailly designed the gzip format and wrote, with Mark Adler,
-   the related software described in this specification.  Glenn
-   Randers-Pehrson converted this document to RFC and HTML format.
-
-6. Author's Address
-
-   L. Peter Deutsch
-   Aladdin Enterprises
-   203 Santa Margarita Ave.
-   Menlo Park, CA 94025
-
-   Phone: (415) 322-0103 (AM only)
-   FAX:   (415) 322-1734
-   EMail: <ghost@aladdin.com>
-
-   Questions about the technical content of this specification can be
-   sent by email to:
-
-   Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
-   Mark Adler <madler@alumni.caltech.edu>
-
-   Editorial comments on this specification can be sent by email to:
-
-   L. Peter Deutsch <ghost@aladdin.com> and
-   Glenn Randers-Pehrson <randeg@alumni.rpi.edu>
-
-
-
-Deutsch                      Informational                     [Page 10]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-7. Appendix: Jean-Loup Gailly's gzip utility
-
-   The most widely used implementation of gzip compression, and the
-   original documentation on which this specification is based, were
-   created by Jean-Loup Gailly <gzip@prep.ai.mit.edu>.  Since this
-   implementation is a de facto standard, we mention some more of its
-   features here.  Again, the material in this section is not part of
-   the specification per se, and implementations need not follow it to
-   be compliant.
-
-   When compressing or decompressing a file, gzip preserves the
-   protection, ownership, and modification time attributes on the local
-   file system, since there is no provision for representing protection
-   attributes in the gzip file format itself.  Since the file format
-   includes a modification time, the gzip decompressor provides a
-   command line switch that assigns the modification time from the file,
-   rather than the local modification time of the compressed input, to
-   the decompressed output.
-
-8. Appendix: Sample CRC Code
-
-   The following sample code represents a practical implementation of
-   the CRC (Cyclic Redundancy Check). (See also ISO 3309 and ITU-T V.42
-   for a formal specification.)
-
-   The sample code is in the ANSI C programming language. Non C users
-   may find it easier to read with these hints:
-
-      &      Bitwise AND operator.
-      ^      Bitwise exclusive-OR operator.
-      >>     Bitwise right shift operator. When applied to an
-             unsigned quantity, as here, right shift inserts zero
-             bit(s) at the left.
-      !      Logical NOT operator.
-      ++     "n++" increments the variable n.
-      0xNNN  0x introduces a hexadecimal (base 16) constant.
-             Suffix L indicates a long value (at least 32 bits).
-
-      /* Table of CRCs of all 8-bit messages. */
-      unsigned long crc_table[256];
-
-      /* Flag: has the table been computed? Initially false. */
-      int crc_table_computed = 0;
-
-      /* Make the table for a fast CRC. */
-      void make_crc_table(void)
-      {
-        unsigned long c;
-
-
-
-Deutsch                      Informational                     [Page 11]
-
-RFC 1952             GZIP File Format Specification             May 1996
-
-
-        int n, k;
-        for (n = 0; n < 256; n++) {
-          c = (unsigned long) n;
-          for (k = 0; k < 8; k++) {
-            if (c & 1) {
-              c = 0xedb88320L ^ (c >> 1);
-            } else {
-              c = c >> 1;
-            }
-          }
-          crc_table[n] = c;
-        }
-        crc_table_computed = 1;
-      }
-
-      /*
-         Update a running crc with the bytes buf[0..len-1] and return
-       the updated crc. The crc should be initialized to zero. Pre- and
-       post-conditioning (one's complement) is performed within this
-       function so it shouldn't be done by the caller. Usage example:
-
-         unsigned long crc = 0L;
-
-         while (read_buffer(buffer, length) != EOF) {
-           crc = update_crc(crc, buffer, length);
-         }
-         if (crc != original_crc) error();
-      */
-      unsigned long update_crc(unsigned long crc,
-                      unsigned char *buf, int len)
-      {
-        unsigned long c = crc ^ 0xffffffffL;
-        int n;
-
-        if (!crc_table_computed)
-          make_crc_table();
-        for (n = 0; n < len; n++) {
-          c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8);
-        }
-        return c ^ 0xffffffffL;
-      }
-
-      /* Return the CRC of the bytes buf[0..len-1]. */
-      unsigned long crc(unsigned char *buf, int len)
-      {
-        return update_crc(0L, buf, len);
-      }
-
-
-
-
-Deutsch                      Informational                     [Page 12]
-
author	cvs2git <rtems-devel@rtems.org>	1996-09-30 20:15:02 +0000
committer	cvs2git <rtems-devel@rtems.org>	1996-09-30 20:15:02 +0000
commit	43e1177def5a04b962b591496b2990e1c57ce63e (patch)
tree	fc1be17df72a87979f270adb59423ca71992b18b /cpukit/zlib
parent	fixed incorrect placement of CPU_STRUCTURE_ALIGNMENT macro. (diff)
download	rtems-43e1177def5a04b962b591496b2990e1c57ce63e.tar.bz2