On 18/03/2025 15:10, Waldek Hebisch wrote:It would be a little more accurate (in C terminology) to call it an "unspecified value" rather than an "undefined value" - gcc, and many other compilers, treat that as meaning "a" gets a valid int value, but you don't care which value it is. Using the value in "a" is allowed - i.e., it is not considered as undefined behaviour by the compiler. (I am not sure if the C standards require "int a = a;" to be treated like that - I suspect that it is undefined behaviour from the standards viewpoint, but defined by the implementation.)bart <bc@freeuk.com> wrote:On 18/03/2025 12:17, Waldek Hebisch wrote:A declaration like:There were some tweaks needed; it indicates some basic info missing from>
my write-up! (For example, that the function call needs to be bar() not
bar; 'const' is only for compile-time expressions; and that C's 'const'
doesn't exist - it only briefly mentions an attempt at 'let'.)
>
The revised code is shown below, with what I assumed were your
intentions.
Well, my intentions beter correspond to the C version below:
>
int foo() {
const int c = c1(10);
const int b = c + c2(2);
const int a = b+c3(c);
bar();
baz();
return c;
}
>
Part of the question was if "execution" of declarations is
interleaved with execution of code or if declarations go
before the code.
int a := x
can be considered to be:
int a; a := x
where the declaration can go anywhere in the scope=, but the assignment must be done here. There are languages where you have:
print x
where x is ...
But the typical usage pattern in my own programs is that local variable are declared before first use.
(Maybe a compiler option can enforce that, but I don't see it as critical.)
That doesn't happen here:print a>
int a:=100
>
the assignment is done at that place in the code (after print), but the
scope of 'a' is function-wide. My compiler doesn't detect accesses to
unitialised variables, but I could add a debug option to clear
stack-frame variables on function entry.)
I see. So your feature conflicts with C feature "variable which is
initialized at declaration time is always used initialized".
int a = a;
gcc (with no extra options) tcc and bcc both put some undefined value in a.
gcc won't warn until you say '-Wextra', and then only for:>
> int a = a + 1;
People would not normally write "int a = a;". It is used as a common idiom meaning "I know it is not clear to the compiler that the variable is always initialised before use, but /I/ know it is - so disable the use-without-initialisation warnings for this variable". So it makes perfect sense for the compiler not to warn about it!
gcc does have a "-Winit-self" warning (not part of -Wall or -Wextra) that will warn on "int a = a;". (It is enabled by -Wall in C++, however, since in C++ such code can have very different semantics for more advanced types.)
"int a = a + 1;", on the other hand, clearly attempts to read the value of "a" before it is initialised, and a warning is issued if "-Wuninitialized" is enabled. This warning is part of "-Wall".
| Date | Sujet | # | Auteur | |
| 6 May 26 |  … |
Les messages affichés proviennent d'usenet.