> > > My questions are:
> > >
> > > - How do I get the 32 bit ARG_MAX value from
> inside a
> > > 64 bit program?
> >
> > Well, unless someone adds an _SC_ARG32_MAX and
> _SC_ARG64_MAX,
>
> There is
>
> #define _ARG_MAX32 1048320 /* max length of args
> to exec 32-bit program */
> #define _ARG_MAX64 2096640 /* max length of args
> to exec 64-bit program */
If getting those values at compile time rather than at run time is good enough,
that's fine, although those aren't portable. I was looking for an answer that
would work on more than just Solaris, and there don't seem to be good answers
for that.
> > I suppose you need to popen() a helper program of
> the bitness other
> > than your own that looks this up for you. You'd
> want to have a flag,
> > so you only did that the first time you needed to
> know, and cached
> > the value for subsequent use.
>
> This does not seem to be a good solution
Agreed that it's ugly and for short scripts inefficient, but it should be
portable.
> > > - What is the best way to detect whether "cmd" is
> a
> > > 32 os a 64 bit binary?
> >
> > I'm not sure that's generally answerable. If the
> executable is also readable,
> > you can do anything from run "file" on it to using
> the libelf functions (or the
> > even more generic and portable GNU bfd library if
> available) to discover its
> > type, with a library call of course being much more
> efficient than calling an
> > external program. But an executable doesn't have
> to be readable, in which
> > case I suppose you have to make the safer
> assumption, in this case that it's
> > a 32-bit process.
>
> Well, there is gelf_getclass()
Right...that's in libelf. But as I said, you still end
up having to make the safer assumption when you
can't use that on an execute-only binary. So I really
wonder if it's worth the bother for just a factor of two
difference.
> > In general, I have a problem with people using
> insanely large argument lists;
>
> Then you seem to missunderstand the background.
>
> > a directory with hundreds of thousands of files
> probably won't perform well
> > anyway, and aside from wildcard expansions, there's
> really no excuse _at_all_,
> > for it IMO (and it's their responsibility to only
> use wildcards when their expansions
>
> I am not sure if you ever did think about the
> problem.
>
> - Your keyword "wildcard" does not apply at all
Maybe not to what you want to do, but the basic problem
remains that whatever the fixed limit is, a robust solution
should be able to work with more than that.
> - Try to write a simple command that count the lines
> of code in ON
My answer would be don't restrict the solution to shell scripts, do
it in perl, where all the needed functionality is built into the language;
no need to fork/exec anything other than the perl interpreter itself.
That would also give the flexibility to later count comments separately
from source, etc. since perl is great at pattern matching.
> > could safely be expected to be reasonable sized).
> That's what xargs, or a
> program reading its stdin rather than taking args,
> is for. (And I remember the
> xargs is the wrong solution for a problem - xargs
> does not deal with all
> possible filenames, "find . -exec bla {} +" does.
True; that's the best solution, esp. since the + trick
made it into the standards.
> > really old days when the max arg list size was
> something tiny, like 5120 or so.)
>
> This is the limit from the 1970s. In the mid 1980s it
> was 20000 and since
> SunOS-4.0 it is 1 MB, so the 1 MB limit is 20 years
> old now.
Fine, use the extra memory if it causes the program to
run more efficiently. It doesn't for something like this though.
I think you're looking for too simple a solution,
in particular one that depends on some fixed limit (however large)
being big enough for a growing problem (the ON code base will
likely tend to keep growing, other consolidations could get folded in,
etc). The one good thing about remembering low limits is that they
force you to think about that much earlier.
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
