ISO_ERR_PRIO and error return -1

[scdbackup]

In libisofs/messages.c i read

#define ISO_ERR_PRIO(e)     ((e & 0x00F00000) << 8)

which applied to e == -1 would yield a negative priority. Such a message gets queued but then cancelled on delivery by

iso_obtain_msgs("ALL", ...

because LIBISO_MSGS_PRIO_ZERO is 0 and thus higher than undefined negative codes.

A remedy and safety cap would be to change ISO_ERR_PRIO to:

#define ISO_ERR_PRIO(e)     ((e & 0x00700000) << 8)

---

I came to this by a misplaced error simulation. But given the fact that e.g. iso_file_source_open() indeed can return -1, i think the potential to produce undefined severities should be removed.

[vreixo]

It is not a ISO_ERR_PRIO() bug, but a documentation bug.

If correctly defined, a libisofs error will never return an undefined severity/priority. The problem is that libisofs error handling/encoding has been introduced after most of libisofs code (do you remember?), and unfortunatelly many docs were not updated. I mean, the bug is that a function is documented to return -1. Only libisofs encoded errors are actually allowed.

So all functions that are documented as "< 0 error" should actually be documented as "libisofs-encoded error code if error". Note that this problem should only happen on user-implemented interfaces, internally libisofs always return valid codes.

There are lots of such "bugs". The only good solution is to fix the documentation, that of course is an API break.

[scdbackup]

At least one should not allow them to proagate. The highest bit of the bitmask has no legal purpose. One should remove it.

---

I came to the e == -1 experiment from a real -1 return code in libisofs/tree.c:

It causes these messages

libisofs: SORRY : Can't open dir /u
libisofs: NOTE :  > Caused by: Unknown error

In tree.c about half of the error is redirected to a defined one and the other half is left undefined.

    ret = iso_file_source_open(dir);
    if (ret < 0) {
        char *path = iso_file_source_get_path(dir);
        /* instead of the probable error, we throw a sorry event */
        ret = iso_msg_submit(image->id, ISO_FILE_CANT_ADD, ret,
                             "Can't open dir %s", path);
        free(path);
        return ret;
    }

The negative priority emerged, when i placed my synthetic -1 by mistake a few lines deeper, where you call

            ret = iso_msg_submit(image->id, ret, ret, "Error reading dir");

[vreixo]

Fixed on my mainline, revision 376.

Note that this does not fixes the documentation question, that would be fixed soon.