[Re: [GRASS-dev] r.colors: rules file list unsorted]

GRASS GIS GRASS GIS developer
1

ok to commit the attached diff?

It uses scandir() to sort the directory entries alphabetically. I'm not
100% sure scandir can be found on all platforms in which case we need to
do something, like qsort() the names list instead.

What do you think?

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

--

<:3 )---- Wolf Bergenheim ----( 8:>

(attachments)

diff (2.65 KB)

2

Wolf Bergenheim wrote:

It uses scandir() to sort the directory entries alphabetically. I'm
not 100% sure scandir can be found on all platforms in which case we
need to do something, like qsort() the names list instead.

from the scandir(3) man page:

CONFORMING TO
       None of these functions is in POSIX. LSB has deprecated the
       library call alphasort() and never contained scandir().

       The functions scandir() and alphasort() are from BSD 4.3, and
       have been available under Linux since libc4. Libc4 and libc5 use
       the more precise prototype

       int alphasort(const struct dirent **a, const struct dirent **b);

       but glibc 2.0 returns to the imprecise BSD prototype.

       The function versionsort() is a GNU extension, available since
       glibc 2.1. Since glibc 2.1, alphasort() calls strcoll(3); ear-
       lier it used strcmp(3).

.. a POSIX compliant solution would be nice,

Hamish

3

Hamish wrote:

from the scandir(3) man page:

CONFORMING TO
       None of these functions is in POSIX. LSB has deprecated the
       library call alphasort() and never contained scandir().

       The functions scandir() and alphasort() are from BSD 4.3, and
       have been available under Linux since libc4. Libc4 and libc5 use
       the more precise prototype

       int alphasort(const struct dirent **a, const struct dirent **b);

       but glibc 2.0 returns to the imprecise BSD prototype.

       The function versionsort() is a GNU extension, available since
       glibc 2.1. Since glibc 2.1, alphasort() calls strcoll(3); ear-
       lier it used strcmp(3).

.. a POSIX compliant solution would be nice,

My man says:

CONFORMING TO
        None of these functions is in POSIX.1-2001, but alphasort() and
        scandir() are under consideration for a future revision to
        POSIX.1.

So would that satisfy you? Or do you perhaps prefer Daniel's patch, which is perhaps better. Mine is more like a quikfix...

--Wolf

--

<:3 )---- Wolf Bergenheim ----( 8:>

4

I fully agree with Hamish here.

FWIW, Linux and OSX have it. Googling around it seems that Solaris 10
has it, but older Solaris/SunOS versions don't seem to. Ditto for IRIX
and, of course Win32.

Daniel.

On 1/28/07, Hamish <hamish_nospam@yahoo.com> wrote:

Wolf Bergenheim wrote:
> It uses scandir() to sort the directory entries alphabetically. I'm
> not 100% sure scandir can be found on all platforms in which case we
> need to do something, like qsort() the names list instead.

from the scandir(3) man page:

CONFORMING TO
       None of these functions is in POSIX. LSB has deprecated the
       library call alphasort() and never contained scandir().

       The functions scandir() and alphasort() are from BSD 4.3, and
       have been available under Linux since libc4. Libc4 and libc5 use
       the more precise prototype

       int alphasort(const struct dirent **a, const struct dirent **b);

       but glibc 2.0 returns to the imprecise BSD prototype.

       The function versionsort() is a GNU extension, available since
       glibc 2.1. Since glibc 2.1, alphasort() calls strcoll(3); ear-
       lier it used strcmp(3).

.. a POSIX compliant solution would be nice,

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
-- Daniel Calvelo Aros

5

Hamish wrote:

+ struct dirent **d;
..
+ l = scandir(path, &d, 0, alphasort);
..
+ G_free(d[i]);

I am not very good with pointers, but shouldn't there be a G_malloc()
somewhere if G_free() is used?

scandir does the allocation.

or another way: should we keep malloc()+free() separate from
G_malloc()+G_free()? ie don't mix the two?

Isn't G_free just a wrapper for free, so that programmers don't need to worry about linking with correct allocation libraries, and including headers which vary on some UNIX platforms?

--

<:3 )---- Wolf Bergenheim ----( 8:>

6

Daniel Calvelo wrote:

I fully agree with Hamish here.

So do I :wink:

FWIW, Linux and OSX have it. Googling around it seems that Solaris 10
has it, but older Solaris/SunOS versions don't seem to. Ditto for IRIX
and, of course Win32.

Well that kind of does make the decision for us, since we want GRASS to be able to compile natively on Win32, right?

--W

--

<:3 )---- Wolf Bergenheim ----( 8:>

7

On Mon, 29 Jan 2007, Wolf Bergenheim wrote:

or another way: should we keep malloc()+free() separate from
G_malloc()+G_free()? ie don't mix the two?

Isn't G_free just a wrapper for free, so that programmers don't need to worry about linking with correct allocation libraries, and including headers which vary on some UNIX platforms?

According to the programmers manual:

"The following routines provide memory allocation capability. They are simply calls to the UNIX suite of memory allocation routines malloc( ), realloc( ) and calloc( ), except that if ther is not enough memory, they print a diagnostic message to that effect and then call exit( ).
Note. Use the G_free( ) routine to release memory allocated by these routines."

So in practice they are the same, but I think it is cleaner programming and safer in the long run not to mix malloc() with G_free() etc.

Paul

8

Wolf Bergenheim wrote:

> from the scandir(3) man page:
>
> CONFORMING TO
> None of these functions is in POSIX. LSB has deprecated the
> library call alphasort() and never contained scandir().
>
> The functions scandir() and alphasort() are from BSD 4.3, and
> have been available under Linux since libc4. Libc4 and libc5 use
> the more precise prototype
>
> int alphasort(const struct dirent **a, const struct dirent **b);
>
> but glibc 2.0 returns to the imprecise BSD prototype.
>
> The function versionsort() is a GNU extension, available since
> glibc 2.1. Since glibc 2.1, alphasort() calls strcoll(3); ear-
> lier it used strcmp(3).
>
>
>
> .. a POSIX compliant solution would be nice,
>

My man says:

CONFORMING TO
        None of these functions is in POSIX.1-2001, but alphasort() and
        scandir() are under consideration for a future revision to
        POSIX.1.

So would that satisfy you?

Not me; use opendir/readdir/closedir + qsort instead.

MinGW provides implementations of these functions on Windows, or you
can use the native functions FindFirstFile, FindNextFile and FindClose
instead.

--
Glynn Clements <glynn@gclements.plus.com>