Michael L Gueterman writes:
>
> Let me (sort of) answer your first question by relaying some information
> I found out from HP just a couple days ago.
>   A customer of mine is developing an application that requires some of the
> Posix Developers Kit libraries.  They had been compiling from the CI using the
> CCXL command file mixing libraries located in HFS and CI filespace.  For
> reasons I won't get into, this wasn't "A good thing" (TM Martha Stewart :).
> I poked around, and the 'HP Officially Supported Solution' was:
>
> .  If you compile using HP supplied Posix libraries, compile from within
>    the shell, and do not use the equivalent HP supplied CI libraries.

I understand why you don't want want to use those CI libraries.

> .  If you compile using the HP supplied Posix libraries, you *MUST* execute
>    your program from within the shell.  This one surprised me a bit and I
>    asked this same question a couple of times to make sure I was hearing them
>    correctly.
>
>   The reasons given (and I can understand them now) were that even though some
> of the functions are duplicated between the libraries, the buffer sizes used may
> not be equivalent.

I have trouble understanding this.  Perhaps the HPRC person is mis-informed
(it's been known to happen) or didn't explain it well.

I compile a program using the /lib/lib*.a and /usr/lib/lib*.a libraries.  I can
run the NMPRG from sh and everything works fine.

I now take that same NMPRG and invoke it from the CI, and perhaps the program
fails.  Why?  It's the same NMPRG with the same external references.  The only
thing different is the initial execution environment, i.e. spawned via
CREATEPROCESS() in the CI or via fork()/exec() in sh.

What's different about the execution environment?  The only thing I've *ever*
found is that CI doesn't initialize argv[0] quite the same way that sh does.
You'll probably inherit slightly different opened system files, but I haven't
seen this to be a problem.

> Therefore, if you compile using a Posix Library and
> subsequently execute it under the CI, you *may* get into a situation where you
> start overwriting things in memory that you didn't anticipate.
>   It sounds like for the vast majority of things, this is probably not a problem,
> but it potentially could be.  Therefore, in order for the application to be
> in a "supportable" condition, you must keep things separate.

I'm extremely skeptical that buffer overflows are possible.

As I mentioned above, programs that check argv[0] to see what name they were
invoked by in order to perform varying functionality might not react as
expected, but that won't be an abort.

>   To me, this reeks of the "Jeanette Nutsford Berlin Wall"condition that I
> had thought was crumbling (puns intended).  I had been under the impression
> up to this point that if I had a NMPRG program, I could safely execute it
> either within or outside of the shell, regardless of how it was created.

We share the same impression.

I encountered this "Berlin Wall" attitude a long time ago from the HPRC.  I
appealed to a lab guy privately who said the HPRC was wrong and that the
particular engineer would be re-educated.
--
Mark Bixby                      E-mail: [log in to unmask]
Coast Community College Dist.   Web: http://www.cccd.edu/~markb/
District Information Services   1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
Technical Support               Voice: +1 714 438-4647
"You can tune a file system, but you can't tune a fish." - tunefs(1M)