We are running on a 4 cpu L2000 with HP-UX_B.11.00_32/64 with the
lastest recommended patch bundle.

Also, we are using HP C/ANSI C B.11.02.10.

We are experiencing 2 problems:
1) if a user has the UNIX95 variable in their .profile, cc will fail
with error 1469 (cc cannot open file xxx.h). Once this variable is
removed, it functions. We'd like to keep the variable if possible.
Any ideas what is wrong?

2) we are trying to suppress a warning during or compile (warning
2028) with the +w switch. Unfortunately, this does not disable the
warning even though the man page states that it should. Is teh +w
switch no longer a valid option?

Any help is greatly appreciated.

dorth (dorthensensens@hotmail.com) wrote:
: we are using HP C/ANSI C B.11.02.10.
: 1) if a user has the UNIX95 variable in their .profile, cc will fail
: with error 1469 (cc cannot open file xxx.h). Once this variable is
: removed, it functions. We'd like to keep the variable if possible.
: Any ideas what is wrong?

It helps if you quote the error exactly. I assume it is:
cc: error 1469: Cannot open 'XXX' for -I directory search

Ah, is it this message?
1469 Cannot open '!2' for !1 directory search
Requirement: UNIX Branding
Mode: Strict ANSI only
Cause:
A directory has been specified to be included via the -I or -L command
which is either
- not present
- not readable
- not searchable

The Unix95 Standard says an error must be given in the case of c89.
There was a bug in this error checking, so you would always get an error
with c89 and UNIX95. This is CR JAGaf29402:
Error 1469 UNIX95= c89 -I fails, prevents Standards tests from compiling

So you either unset it or use cc instead.

: 2) we are trying to suppress a warning during or compile (warning
: 2028) with the +w switch. Unfortunately, this does not disable the
: warning even though the man page states that it should. Is the +w
: switch no longer a valid option?

+W### option only suppresses compiler messages. 2028 comes from cpp.ansi.

2028 %2$s, line %3$d: warning %1$d:
Found comment inside comment started on line %4$d.

Dennis,
Thank you for replying, here are some follow ups...

dhandly@convex.hp.com (Dennis Handly) wrote in message

> It helps if you quote the error exactly. I assume it is:
> cc: error 1469: Cannot open 'XXX' for -I directory search

This is correct.

> Ah, is it this message?
> 1469 Cannot open '!2' for !1 directory search
> Requirement: UNIX Branding
> Mode: Strict ANSI only
> Cause:
> A directory has been specified to be included via the -I or -L command
> which is either
> - not present
> - not readable
> - not searchable

that's the bug. this error is incorrectly generated when the directory
(1) is
present and (2) is readable and (3) is searchable

> The Unix95 Standard says an error must be given in the case of c89.
> There was a bug in this error checking, so you would always get an error
> with c89 and UNIX95. This is CR JAGaf29402:
> Error 1469 UNIX95= c89 -I fails, prevents Standards tests from compiling

Is the bug not fixed by the latest available patches? does that mean
the hp 'C' compiler is not standards compliant?
this is a big worry as our codebase *demands* a standards compliant
'C' compiler.

> So you either unset it or use cc instead.

if hp is unable to fix this bug can hp (or anyone) recommend a
standards-compliant 'C' compiler,
like 'gcc', to use instead? a non-compliant 'C' compiler is of no use
to us

> +W### option only suppresses compiler messages. 2028 comes from cpp.ansi.
>
> 2028 %2$s, line %3$d: warning %1$d:
> Found comment inside comment started on line %4$d.

has hp documented this unusual behavior anywhere? none of the other
unix 'C'
compliers we use (dunix, aix, solaris, gcc, sgi) treat preprocessor
warnings
this way, ie, cpp warnings are disjoint (and unsupressable) from cc
warnings

Thanks again.

dorth (dorthensensens@hotmail.com) wrote:
: > The Unix95 Standard says an error must be given in the case of c89.

We claim the Unix95 Posix Standard does not say what the branding test was
testing. Basically it was testing to make sure that if you use -IFOO
or -LFOO, that directory had to exist. But rather than fight it, we
implemented a check for the existence of that path. This works fine on IPF.

: > There was a bug in this error checking, so you would always get an error
: > with c89 and UNIX95. This is CR JAGaf29402:
: > Error 1469 UNIX95= c89 -I fails, prevents Standards tests from compiling

: Is the bug not fixed by the latest available patches?

I'm not sure, there doesn't appear to be a patch.
Though there is a fix for the 11.23 0409 release.

: does that mean the hp 'C' compiler is not standards compliant?

I wouldn't say that. It works fine as long as you don't use c89 or
export UNIX95.

: a non-compliant 'C' compiler is of no use to us

Compliant to what?

: has hp documented this unusual behavior anywhere? none of the other unix 'C'
: compliers we use (dunix, aix, solaris, gcc, sgi) treat preprocessor warnings
: this way, ie, cpp warnings are disjoint (and unsupressable) from cc
: warnings

Perhaps not. But in my mind, +W always worked on compiler messages, not
driver or preprocessor. Especially if there were overlaps in numbers.