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

[Andreas Lange]

Glynn, 

no doubt, what you say is completely correct. Thanks a lot for pointing
the details out. 

But i have not the time to read the complete code and just wanted to get
the postgresql modules to compile. Its not my code anyway. 

If someone has time and a better solution, please go ahead. I am always
in favour of a perfect solution, but want to go on with the windows
port. Many problems are still ahead...

cu,

Andreas 

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

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
url: http://mitglied.tripod.de/AndreasLange
mail: Andreas.Lange_at_Rhein-Main.de - A.C.Lange_at_GMX.net