So we keep putting our trust in things that rust
And then we feel the pain of loss
(James, "Stripmining")

Known Bugs, Problems and Limitations

Every program sucks. Read why this program sucks, too.

Panic messages

This is a special kind of messages which do not fit into the scema of all those messages described at another chapter. When processing it's input, hsc does not only check if the user made a mistake, but also the author of this tools. At several places of the source code, hsc tests for things that must not happen. Otherwise, hsc asumes it has completely fucked up. In this case, it simple displays a message on the screen and aborts.

An example panic message could look like this:

  ** PANIC at "hugo.c" (123): sepp is not at home

These messages are not really meant to be interpreted by the user, but by the programmer. When hsc puts out a panic message, you should contact the author and report this bug, including the complete text of the panic message.

Known bugs

The problems below should be fixed.. sometimes.

You should try to avoid using a project file and pipes together; altough hsc should now be able to cope with this without enforcer hits, it might still behave unreasonable and end up with funny project files and dependencies.
There seems to be a problem with GETSIZE for machines based on CPUs that do not support networking byte order (like those from wIntel).
I'm still not sure, if GETSIZE for JFIF/JPEG can handle everything correct - but hopefully it does. I've really never seen such an idiotic, brain-dead, ill-minded and chaotically structured image-format before.

Known problems (to be fixed)

The problems below are no real bugs and should be fixed.. sometimes.

Most NEXT and PREV buttons of the documentation does not fit; I just wanted to show how to create a navigation bar, but I'm too lazy to maintain it while the structure of the documentation isn't fixed.
As I know myself, these documents still contain loads of typos and ``strange English''..

Known problems

The problems described below probably won't ever be fixed.

URI checking is performed via trying to open a file. As AmigaOS is case-insensitive dealing with filenames, problems might occur when copying the html-object-tree to a case-sensitive file system. I recommend to rebuild the whole project at the target system.
If you specify a <BASE HREF="..">, hsc is unable to find out how the base is related to the destination-directory and will treat all local URIs like external ones; Absolute URIs aren't possible with a base-URI set, of course.
The obsolete tags <LISTING> and <XMP> might not be treated correctly, as the behavior of these two seems so be not very strictly defined. You should avoid them anyway and use <PRE> or <$source> instead.
hsc doesn't care much about filenames and their limitations; if, for example, a filename gets too long, it depends on fopen() of your compiler whether an error is reported or the filename is truncated. If you insist on filenames containing 46587643 characters, hsc can cope with it - but your OS probably won't.
Out-of-memory can cause small memory-leaks. This is because hsc uses a special malloc()-function which just displays an error message and quits using exit(). As hsc keeps track of all allocated resources, it will release everything that could be fully initialised and made it into its supposed resource-list. For out-of-memories during partially initialising complex structures, this fails and can cause memory-leaks (normally approx. 100-500 bytes). Usually, these are handled by your OS or, as for AmigaOS, by the malloc()-function of the run-time-library, so you shouldn't bother too much about that. Blame K&R for their brain-damaged memory-management concepts.
GetFileSize() probably won't work correctly on files greater than 2 GB.
Until now I couldn't test hsc on some 64-bit OS, so problems might occur if data leave 32-bit address-space.

Limitations

hsc is fully dynamic and it's input size, number of syntax-elements and etc. is only limited by memory and disk-space. Only some less important status messages are created in classic, brain-dead zero-terminated C-character-arrays and are truncated if they become too long.

However, for projects much larger then 100 documents, scanning the project-file on every run takes an awful lot of time; due the lack of any portable concept of keeping data resident after a program exits, there is no workaround for this (same problem like with hsc.prefs); you will have to get rid of the project-file and hscdepp for such projects.