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.
Hi, On Sun, Jun 03, 2012 at 12:13:41AM +0400, 123 wrote:
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. -- Cheers Jorge.-
On Sat, Jun 02, 2012 at 05:23:52PM -0400, Jorge Arellano Cid wrote:
Hi,
On Sun, Jun 03, 2012 at 12:13:41AM +0400, 123 wrote:
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).
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.
On Sun, Jun 03, 2012 at 05:52:43PM +0400, 123 wrote:
On Sat, Jun 02, 2012 at 05:23:52PM -0400, Jorge Arellano Cid wrote:
Hi,
On Sun, Jun 03, 2012 at 12:13:41AM +0400, 123 wrote:
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?
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. -- Cheers Jorge.-
Jorge Arellano Cid wrote:
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
participants (3)
-
jcid＠dillo.org -
onepoint＠starurchin.org -
p37sitdu＠lavabit.com