afscp coredumps when a directory is full

[hoglet67]

Full seems to be 47 entries.

Here's a stack trace:

(gdb) bt
#0  __memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:127
#1  0x000055e634cee828 in dir_makeslot (parent=0x7fff7f2d6290, ent=0x55e6361e766b "") at acorn-adfs.c:482
#2  0x000055e634cee94b in adfs_save (fs=0x55e63617c260, obj=0x7fff7f2d6150, dest=0x7fff7f2d6290) at acorn-adfs.c:504
#3  0x000055e634ceb752 in save_file (obj=0x7fff7f2d6150, ctx=0x7fff7f2d6260) at afscp.c:195
#4  0x000055e634cebb72 in copy_loop (argc=1, argv=0x7fff7f2d6570, ctx=0x7fff7f2d6260) at afscp.c:262
#5  0x000055e634cebcf7 in acorn_dest (argc=49, argv=0x7fff7f2d63f8, fsname=0x7fff7f2d82b1 "AcornFileStore.dat", dest=0x55e634cf054f "$")
    at afscp.c:293
#6  0x000055e634cec094 in main (argc=49, argv=0x7fff7f2d63f8) at afscp.c:358

[SteveFosdick]

I believe this is fixed in 2e15f31

The issue was actually in the search() function. The calling convention is that when it reports a file as not being found, if the the pointer returned through *ent_ptr is NULL the directory is full, i.e. search had to go right to the end and still didn't find it whereas if the returned pointer is non-NULL it is the correct place to insert the new entry (to keep them sorted). Search was running on too far into the directory footer.