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

Eric G. Miller egm2 at jps.net
Wed Aug 8 23:04:53 EDT 2001


On Wed, Aug 08, 2001 at 08:39:04PM +0100, Glynn Clements wrote:
> 
> 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?

I'll take credit for that.  It was statically defined as 1024 before.  I
can't remember why I used it... I was focused on fixing up the calls to
parser code...

> 
> 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.

Trivial changes would do this.  
In "main.c": 
  Eliminate ARG_MAX and <limits.h>.  
  Change for() loop reading file to:
    for (stmt_sz = 1024; ; stmt_sz += 1024) {...}

Course, someone could specify /dev/random and exhaust system memory, but
presumably we have trusted users ;)

-- 
Eric G. Miller <egm2 at jps.net>



More information about the grass-dev mailing list