[patch] dlib cleanup

[123]

malloc.diff: added perror calls for malloc and realloc errors

dstr.diff: dStr* functions cleanup

dlist.diff: replaced recursive QuickSort with qsort from stdlib.h.
Tested with file.dpi where it is used for sorting directory listing.

[Jorge Arellano Cid]

Hi,

Post by 123
malloc.diff: added perror calls for malloc and realloc errors
dstr.diff: dStr* functions cleanup
dlist.diff: replaced recursive QuickSort with qsort from stdlib.h.
Tested with file.dpi where it is used for sorting directory listing.

There're different criteria to write code. In dlib, a few lines
are preferred to a single contracted one to make it simpler to
understand. In the same spirit, scattered return statements are avoided
to make code path following simpler.

For quick sort I remember having to implement it in dlib because
stdlib's qsort varies among platforms.

[123]

Post by Jorge Arellano Cid
Hi,

Post by 123
malloc.diff: added perror calls for malloc and realloc errors
dstr.diff: dStr* functions cleanup
dlist.diff: replaced recursive QuickSort with qsort from stdlib.h.
Tested with file.dpi where it is used for sorting directory listing.

There're different criteria to write code. In dlib, a few lines
are preferred to a single contracted one to make it simpler to
understand. In the same spirit, scattered return statements are avoided
to make code path following simpler.

What about perror in malloc? It is still better than silent exit(1).

Post by Jorge Arellano Cid
For quick sort I remember having to implement it in dlib because
stdlib's qsort varies among platforms.

I can only find reports about problems in Solaris qsort related to
performance. There should be no known problems in platforms listed on
http://www.dillo.org/Compatibility.html and qsort is a part of
POSIX/SUS.

qsort is also used in lout/container.cc so broken qsort will break
dillo anyway.

[Jorge Arellano Cid]

Post by 123

Post by Jorge Arellano Cid
Hi,

Post by 123
malloc.diff: added perror calls for malloc and realloc errors
dstr.diff: dStr* functions cleanup
dlist.diff: replaced recursive QuickSort with qsort from stdlib.h.
Tested with file.dpi where it is used for sorting directory listing.

There're different criteria to write code. In dlib, a few lines
are preferred to a single contracted one to make it simpler to
understand. In the same spirit, scattered return statements are avoided
to make code path following simpler.

What about perror in malloc? It is still better than silent exit(1).

Yes, it looks better.

Some C libs leave errno unset, and others always set it to ENOMEM.
Please excuse my ignorance, but what other error conditions may malloc
return?

Post by 123

Post by Jorge Arellano Cid
For quick sort I remember having to implement it in dlib because
stdlib's qsort varies among platforms.

I can only find reports about problems in Solaris qsort related to
performance. There should be no known problems in platforms listed on
http://www.dillo.org/Compatibility.html and qsort is a part of
POSIX/SUS.
qsort is also used in lout/container.cc so broken qsort will break
dillo anyway.

AFAIR, there were some qsort receiving different types of arguments
or behaving a bit different with some special border cases. I'll try
to find what was it in the archives...

Non uniform treatment in dlib/dillo is a bug. Unless we know
that in container.cc we don't ever fall in one of the special
cases.

[Jeremy Henty]

Post by Jorge Arellano Cid
Some C libs leave errno unset, and others always set it to ENOMEM.
Please excuse my ignorance, but what other error conditions may
malloc return?

According to the man pages on my Linux system:

The Unix98 standard requires malloc(), calloc(), and realloc() to
set errno to ENOMEM upon failure. Glibc assumes that this is done
(and the glibc versions of these routines do this); if you use a
private malloc implementation that does not set errno, then
certain library routines may fail with- out having a reason in
errno.

So, unless we support systems that do not conform to Unix98, then I
read this as saying that ENOMEM is the only error we will see.

Regards,

Jeremy Henty