AIX C compiler message unexplainable

[andreas.luethi]

Hi All

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000 ) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling the
same sources with other compiles such as AIX version 7.0, gcc on
linux etc do not display this information.

Appreciate your help in this regard,

Thanks,
Andreas

[Eric Sosman]

jacob navia wrote:

Roberto Waltman wrote:

>>
void aaalib_trim (char *in) {
int n = strlen(in) - 1;
for ( ; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen(in) is always greater than 1, right? ;)

strlen can be zero. Then, strlen(in)-1 is -1.

Actually, `strlen("")-1' is `(size_t)-1', an unsigned
value that is at least 65535 and possibly larger. On most
systems, converting this large value to an `int' will yield
the value -1, but that's just dumb luck and not a feature
of the C language.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[A. Bolmarcich]

On 2007-10-17, an************@ gmx.net <an************ @gmx.netwrote:

On Oct 17, 1:13 pm, jacob navia <ja...@nospam.o rgwrote:

>andreas.lue... @gmx.net wrote:

Hi All

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000 ) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

[snip]

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

Does the compiler write the message when you compile that snippet?
What compiler options are you using?

[Keith Thompson]

an************@ gmx.net writes:

On Oct 17, 1:13 pm, jacob navia <ja...@nospam.o rgwrote:

>andreas.lue... @gmx.net wrote:

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000 ) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

[...]

>P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

Did you merely snip that from your program, or did you actually feed
that smaller chunk of code to the compiler? If the latter, you should
add #include directives for <string.hand <ctype.h>.

I get that message when I use "xlc -qinfo=uni", which according to the
man page diagnoses "Possible problems with initialization" . I also
get it with "-qinfo", which enables all such messages (and gives me
over 600 lines of messages for the standard headers).

I'm a little surprised that the message is produced, since n is never
actually used before a value is assigned to it.

The "(I)" denotes an informational message, which is even less severe
than a warning.

Either the "-qinfo=uni" option is slightly buggy, or it's intended to
encourage a programming style in which *all* variables are initialized
when they're defined. Such a style guarantees that all variables will
have defined values when they're accessed (though it doesn't guarantee
that they'll have *meaningful* values).

Determining that n is never actually accessed before a value has been
assigned to it requires dataflow analysis, which is more work for the
compiler.

As far as the standard is concerned, this is all perfectly legitimate.
A compiler is required to produce diagnostics only for syntax errors,
constraint violations, and the #error directive, none of which occur
in your code sample -- but it's allowed to produce any additional
diagnostics it likes.

See the man page for information on how to disable particular messages
(though I suspect that disabling this particular message might disable
messages about actual uses of uninitialized variables). Failing that,
comp.unix.aix is probably a better place to ask. There *might* be a
way to tell the compiler to warn more intelligently about possible use
of uninitialized variables.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[andreas.luethi]

On Oct 17, 11:37 pm, Keith Thompson <[e-mail] rote:

andreas.lue...@ gmx.net writes:

On Oct 17, 1:13 pm, jacob navia <ja...@nospam.o rgwrote:

andreas.lue...@ gmx.net wrote:
Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000 ) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

[...]

P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

Did you merely snip that from your program, or did you actually feed
that smaller chunk of code to the compiler? If the latter, you should
add #include directives for <string.hand <ctype.h>.

I get that message when I use "xlc -qinfo=uni", which according to the
man page diagnoses "Possible problems with initialization" . I also
get it with "-qinfo", which enables all such messages (and gives me
over 600 lines of messages for the standard headers).

I'm a little surprised that the message is produced, since n is never
actually used before a value is assigned to it.

The "(I)" denotes an informational message, which is even less severe
than a warning.

Either the "-qinfo=uni" option is slightly buggy, or it's intended to
encourage a programming style in which *all* variables are initialized
when they're defined. Such a style guarantees that all variables will
have defined values when they're accessed (though it doesn't guarantee
that they'll have *meaningful* values).

Determining that n is never actually accessed before a value has been
assigned to it requires dataflow analysis, which is more work for the
compiler.

As far as the standard is concerned, this is all perfectly legitimate.
A compiler is required to produce diagnostics only for syntax errors,
constraint violations, and the #error directive, none of which occur
in your code sample -- but it's allowed to produce any additional
diagnostics it likes.

See the man page for information on how to disable particular messages
(though I suspect that disabling this particular message might disable
messages about actual uses of uninitialized variables). Failing that,
comp.unix.aix is probably a better place to ask. There *might* be a
way to tell the compiler to warn more intelligently about possible use
of uninitialized variables.

--
Keith Thompson (The_Other_Keit h) [e-mail] <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

The code is only a small snip, the whole source has all the #include
directives.

The make file we use includes an other one from oracle (env_rdbms.mk)
which has a "-qinfo=uni" in it. I could compile with "-qflag=w:w",
that
seems to override the qinfo, but then I also miss all other "(I)"
messages
as well. An other solution is to change the qinfo from env_rdbms.mk in
my
makefile with: "CCFLAGS += -qnoinfo".

The compiler Information "...was not initialized in its declaration"
is of
course true, but as you mentioned n is never accessed before a value
has
been assigned. But this seem to me an unnecessary information unless I
use
such a uninitialized variable.

Andreas

[Mark Bluemel]

an************@ gmx.net wrote:

On Oct 17, 11:37 pm, Keith Thompson <[e-mail] rote:

>andreas.lue... @gmx.net writes:

>>On Oct 17, 1:13 pm, jacob navia <ja...@nospam.o rgwrote:
andreas.lue. [e-mail] wrote:
Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000 ) produces a lot of Informational message
like this:
"aaalib.c ", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

The make file we use includes an other one from oracle (env_rdbms.mk)
which has a "-qinfo=uni" in it.

http://tinyurl.com/26j5b6 suggests that everything is behaving as
designed. The make files request this warning, so the compiler provides it.

I suggest you try adding -qinfo=nouni to your options, after the oracle
make file has been included, if you don't want the information.

[CBFalconer]

an************@ gmx.net wrote:

jacob navia <ja...@nospam.o rgwrote:

>andreas.lue... @gmx.net wrote:

>>Compile a our source with BM XL C/C++ Enterprise Edition V8.0
for AIX (Version: 08.00.0000.0000 ) produces a lot of
Information al message like this:

>>"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n",
which was not initialized in its declaration.

.... snip ...

>
here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen returns a size_t. An int is not necessarily able to hold a
size_t.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

an************@ gmx.net wrote:

>
Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for
AIX (Version: 08.00.0000.0000 ) produces a lot of Informational
message like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n",
which was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling
the same sources with other compiles such as AIX version 7.0, gcc
on linux etc do not display this information.

After close examination of the detailed source provided, I conclude
that the error is in line 42.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Charlie Gordon]

"Eric Sosman" <es*****@ieee-dot-org.invalida écrit dans le message de
news: eZ************* *************** **@comcast.com...

jacob navia wrote:

>Roberto Waltman wrote:

>>>
void aaalib_trim (char *in) {
int n = strlen(in) - 1;
for ( ; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen(in) is always greater than 1, right? ;)

strlen can be zero. Then, strlen(in)-1 is -1.

Actually, `strlen("")-1' is `(size_t)-1', an unsigned
value that is at least 65535 and possibly larger. On most
systems, converting this large value to an `int' will yield
the value -1, but that's just dumb luck and not a feature
of the C language.

That is not dumb luck, it is a well-thought side-effect of 2s complement
representation and wrap-around arithmetics.
IMO, it *should* be made a feature of the language so conversions between
signed and unsigned types always have defined behaviour and be reversible.
Converting a signed type to unsigned and back to signed should produce the
same value, and vice-versa, and should not alter its representation. Most
current architectures have this behaviour (I know MMX/SSE instructions
implement saturated arithmetics, but that's a separate issue).

Mandating this behaviour would effectively retire ones-complement and
sign-magnitude representations , together with padding bits and
trap-representations for integers. Not a big loss, a welcome simplification
of the standard, and a more intuitive behaviour for most programmers.

It would also cut the amount of pedantic noob-bashing on this forum.

--
Chqrlie.

[CBFalconer]

Charlie Gordon wrote:

"Eric Sosman" <es*****@ieee-dot-org.invalida écrit:

.... snip ...

>

>Actually, `strlen("")-1' is `(size_t)-1', an unsigned value that
is at least 65535 and possibly larger. On most systems,
converting this large value to an `int' will yield the value -1,
but that's just dumb luck and not a feature of the C language.

That is not dumb luck, it is a well-thought side-effect of 2s
complement representation and wrap-around arithmetics.

No, it is 'dumb luck'. The conversion to int will probably exceed
the value range of an int, and this always causes an implementation
defined action. Good 2's complementation implementaions (which are
rare) will probably cause a system error to occur.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com