[GRASS5] Re: [winGRASS] ARG_MAX and parser.c

[Glynn Clements]

Andreas Lange wrote:

> There is no ARG_MAX in src/libes/gis/parser.c and there will never be
> one. 
> 
> I just added some ifdefs to
> src.garden/grass.postgresql/d.site.pg/main.c, as this did not compile on
> cygwin. 

Er, why is that file using ARG_MAX anyway?

1. AFAICT, if the statement is longer than ARG_MAX, the code will
simply read the first ARG_MAX bytes of the statement then try to
execute that as an SQL query.

2. The buffer which is being limited to ARG_MAX bytes (SQL_stmt) is
being passed to PQexec(); so why is the limit ARG_MAX bytes? The libpq
documentation (from PostgreSQL 6.5.3) says:

    Caveats
    
    The query buffer is 8192 bytes long, and queries over that length
    will be rejected.

However, I don't see that simply truncating the query helps at all. I
suspect it would be better to just pass the entire query and let
PQexec() reject it.

> On my cygwin install there is no ARG_MAX defined anywhere, only
> _POSIX_ARG_MAX (in limits.h). So i defined ARG_MAX to be _POSIX_ARG_MAX
> if it is undefined. This should be 4096 in any case.  

While we're on the subject of ARG_MAX, it might be worth making a
couple of points in case anyone ever finds a *valid* use for it.

1. ARG_MAX is optional. If it's defined, it should be defined in
<limits.h>, but it isn't required to be defined.

2. If ARG_MAX isn't defined, it may be that the maximum size of an
argument list isn't known until run-time. In this case, the value can
be obtained using sysconf(_SC_ARG_MAX).

3. It's possible that there isn't any limit on the size of an argument
list. In this case, sysconf(_SC_ARG_MAX) will return zero and leave
errno unchanged.

4. In the event that there isn't any limit, the appropriate response
depends upon the context. If you're calling exec(), no problem; you
can give it as much data as you want. OTOH, if you want to allocate a
buffer to store the program's arguments (argv), the only correct
option is to dynamically enlarge the buffer as necessary (which should
probably be done anyway; even if the size is fixed, it could be fixed
at very large value, e.g. more memory than the system actually has).

-- 
Glynn Clements <glynn.clements at virgin.net>