Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ SMAUG coding ➜ Declared variable not "in current context"

Declared variable not "in current context"

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1  2 3  

Posted by Darwin   USA  (125 posts)  Bio
Date Reply #15 on Sun 06 Apr 2008 06:53 AM (UTC)
Message
It appears that removing the -O flag did indeed "fix" the problem. I also don't get any <value optimized out> values for any variables.
Top

Posted by Darwin   USA  (125 posts)  Bio
Date Reply #16 on Sun 06 Apr 2008 08:36 PM (UTC)
Message
A side effect of removing the -O flag has caused some code that previously worked to cause a crash (Segmentation fault.) Placing the -O flag back in and the code doesn't crash. This is something related to some Lua stuff I've added so I'm sure there's a way to remove the -O flag and still have it work correctly, just not sure what it is yet.
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #17 on Sun 06 Apr 2008 11:00 PM (UTC)
Message
It is likely you have used variables which were not initialized - the optimization may have caused the non-initialized value to be something that doesn't crash (eg. zero), whereas the non-initialized value in the un-optimized version may be something else (eg. -38328639764) which would cause a crash.

Make sure you have eliminated all compiler warnings, and check for that sort of thing around the part that crashes. Also use gdb to examine the core dump after the crash.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #18 on Mon 07 Apr 2008 12:02 AM (UTC)
Message
I think that without optimization, variables on the stack get initialized to zero:


$ cat foo.c
#include <stdio.h>

int main(int argc, char** argv)
{
    int i;
    printf("%d", i);
    return 0;
}

$ gcc foo.c -o foo
$ ./foo
0
$ gcc -O2 foo.c -o foo
$ ./foo
2139865432
$   


David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #19 on Mon 07 Apr 2008 12:37 AM (UTC)
Message
Stick to saying they are undefined, I think. Under Linux I got this:


$ cat test.c
#include <stdio.h>

int main()
{
    int i;
    printf("%d", i);
    return 0;
}


$ gcc test.c -Wall -o test
$ ./test
1073830176 $

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Darwin   USA  (125 posts)  Bio
Date Reply #20 on Mon 07 Apr 2008 02:04 AM (UTC)
Message
Ok, I fixed most of all the compiler warnings. I have only a few left and am not sure how these are to be fixed.
Quote:
comm.c: In function ‘new_descriptor’:
comm.c:894: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness

ident.c: In function ‘set_auth’:
ident.c:311: warning: pointer targets in passing argument 3 of ‘getsockname’ differ in signedness
ident.c:316: warning: pointer targets in passing argument 3 of ‘getpeername’ differ in signedness

lua_bits.c: In function ‘bit_tonumber’:
lua_bits.c:65: warning: pointer targets in initialization differ in signedness


The offending lines (in bold):
comm.c
    size = sizeof(sock);
    if ( check_bad_desc( new_desc ) )
    {
      set_alarm( 0 );
      return;
    }
    set_alarm( 20 );
    alarm_section = "new_descriptor::accept";
    if ( ( desc = accept( new_desc, (struct sockaddr *) &sock, &size) ) < 0 )
    {
	perror( "New_descriptor: accept" );
	sprintf(bugbuf, "[*****] BUG: New_descriptor: accept");
	log_string_plus( bugbuf, LOG_COMM, sysdata.log_level );
	set_alarm( 0 );
	return;
    }
    if ( check_bad_desc( new_desc ) )
    {
      set_alarm( 0 );
      return;
    }



ident.c
  if (getsockname(d->descriptor, (struct sockaddr *)&us, &ulen) < 0)
  {
    perror("set_auth: getsockname");
    ENDRET("Set_auth: getsockname error for %s@%s.", "(getsockname error)");
  }
  if (getpeername(d->descriptor, (struct sockaddr *)&them, &tlen) < 0)
  {
    perror("set_auth: getpeername");
    ENDRET("Set_auth: getpeername error for %s@%s.", "(getpeername error)");
  }


lua_bits.c
static int bit_tonumber (lua_State *L)
  {

  Integer result = 0;
  unsigned int base = luaL_optint(L, 2, 10);

  // get text to convert
  const unsigned char * text = luaL_checkstring (L, 1);
  const unsigned char * p;
  unsigned char c;
  unsigned int digit;
  Integer maxvalue;
  int negative = 0;
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #21 on Mon 07 Apr 2008 05:08 AM (UTC)
Message
Quote:
Stick to saying they are undefined, I think. Under Linux I got this:

How odd. I get zero no matter what, and I'm also running Linux. Perhaps it is a compiler version issue: I have gcc 4.1.2.


EDIT: it is true though that one should never depend on anything whatsoever when it comes to unsigned variables. I noticed this initialize-to-zero feature a while ago and didn't like it at the time because it seems like it can introduce subtle bugs that you don't notice until optimizations are turned on. (end edit)


Quote:
comm.c:894: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness

You took the address of an unsigned variable where the function expects a signed variable, or the other way around. Casting to the appropriate type would solve this although you might want to investigate why the signedness is different.

luaL_checkstring, for example, returns a const char*, not a const unsigned char*. Therefore the 'text' variable should not be 'unsigned' -- or, if you really mean 'unsigned' (perhaps it matters later on in the function), you need to cast the result of luaL_checkstring to const unsigned char*.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Isthiriel   (113 posts)  Bio
Date Reply #22 on Mon 07 Apr 2008 05:42 AM (UTC)
Message
Huh.

kc@persephone:~/Desktop$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

kc@persephone:~/Desktop$ cat test.c
#include <stdio.h>

int main() {
    int i;
    printf("%d\n", i);
    return 0;
}

kc@persephone:~/Desktop$ gcc test.c -Wall -o test
kc@persephone:~/Desktop$ ./test
-1209006080
kc@persephone:~/Desktop$ ./test
-1208350720
kc@persephone:~/Desktop$ ./test
-1209026560
kc@persephone:~/Desktop$ gcc -O2 test.c -Wall -o test
test.c: In function 'main':
test.c:5: warning: 'i' is used uninitialised in this function
kc@persephone:~/Desktop$ ./test
1
kc@persephone:~/Desktop$ ./test
1
kc@persephone:~/Desktop$ ./test
1
kc@persephone:~/Desktop$ 


Wouldn't it be a compiler/target option somewhere?
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #23 on Mon 07 Apr 2008 05:57 AM (UTC)
Message
Quote:

it is true though that one should never depend on anything whatsoever when it comes to unsigned variables


You mean, "undefined variables".

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #24 on Mon 07 Apr 2008 06:04 AM (UTC)
Message
Quote:

Wouldn't it be a compiler/target option somewhere?


I can't see one, and in any case I don't think the correctness of a C program should depend on the compile-time options.

Basically it is incorrect to assume that uninitialized automatic variables (those on the stack) have anything but undefined values.

As you can see from the various tests, you may well get consistent results from one test to the next, and under certain circumstances, the value may be zero, but you can't assume that.

See: http://c-faq.com/decl/initval.html

I quote (my emphasis):

Quote:

Variables with automatic duration (i.e. local variables without the static storage class) start out containing garbage, unless they are explicitly initialized. (Nothing useful can be predicted about the garbage.)


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #25 on Mon 07 Apr 2008 06:26 AM (UTC)

Amended on Mon 07 Apr 2008 06:29 AM (UTC) by Nick Gammon

Message
What's interesting to me is that for as long as I can remember, developing on this and other similar Linux systems, every single time I've looked at uninitialized stack variables in the debugger, they've been zero. And when optimization was turned on, they were garbage.

This behavior shouldn't be depended upon (of course) but it's interesting that it was so consistent for me...

IIRC, the Visual Studio libraries have different initialization behavior for the debug and optimized versions, but I haven't played with those for quite a long time.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Isthiriel   (113 posts)  Bio
Date Reply #26 on Mon 07 Apr 2008 09:33 AM (UTC)
Message
Quote:
I can't see one, and in any case I don't think the correctness of a C program should depend on the compile-time options.


It's not so much the correctness of the program as the dialect of C you are forcing the compiler to expect, which can be altered by compile time options (and pragmas &c..). For.ex. there are target options to control whether a 'long long' is 32 or 64 bits wide.

Quote:
What's interesting to me is that for as long as I can remember, developing on this and other similar Linux systems, every single time I've looked at uninitialized stack variables in the debugger, they've been zero. And when optimization was turned on, they were garbage.


Debuggers are famous for 'fixing' problems that occur outside of the debugger by doing things like zeroing variables.
Top

Posted by Darwin   USA  (125 posts)  Bio
Date Reply #27 on Tue 08 Apr 2008 12:25 AM (UTC)
Message
Quote:
You took the address of an unsigned variable where the function expects a signed variable, or the other way around. Casting to the appropriate type would solve this although you might want to investigate why the signedness is different.
Well, actually, I didn't do any of those. They're all parts of stock code.

Quote:
luaL_checkstring, for example, returns a const char*, not a const unsigned char*. Therefore the 'text' variable should not be 'unsigned' -- or, if you really mean 'unsigned' (perhaps it matters later on in the function), you need to cast the result of luaL_checkstring to const unsigned char*.


Changing the 'text' variable to const char * instead of const unsigned char * yields an error when compiling. That part is from Nick's Lua code
lua_bits.c: In function ‘bit_tonumber’:
lua_bits.c:79: warning: pointer targets in assignment differ in signedness
lua_bits.c:108: error: invalid operands to binary -


Line 108 is bolded.
static int bit_tonumber (lua_State *L)
  {

  Integer result = 0;
  unsigned int base = luaL_optint(L, 2, 10);

  // get text to convert
  const char * text = luaL_checkstring (L, 1);
  const unsigned char * p;
  unsigned char c;
  unsigned int digit;
  Integer maxvalue;
  int negative = 0;

  if (base != 10)
    luaL_argcheck(L, 2 <= base && base <= 36, 2, "base out of range");

  // maximum value before multiply by the base
  maxvalue = 4503599627370496 / base;   // 2^52

  // skip whitespace
  for (p = text; isspace (*p); p++)
    ;  // skip leading spaces

  // look for sign
  if (*p == '-')
    {
    negative = 1;
    p++;
    }
  else if (*p == '+')
    p++;


  while ((c = *p++))
    {

    // The largest mantissa a double can have it 52 bits
    if (result >= maxvalue)
      luaL_error (L, "Number too big");

    if (isdigit (c))
      digit = c - '0';
    else if (isalpha (c))
      digit = toupper (c) - 'A' + 10;
    else
      digit = 999;   // bad digit - force error in next line

    if (digit >= base)
      luaL_error (L, "Bad digit ('%c') at position %i",
                  c, (int) (p - text));

    result = result * base + digit;
    } // end while

  if (negative)
    result = -result;

  lua_pushnumber (L, result);

  return 1;  // number of result fields
  } // end of bit_tonumber
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #28 on Tue 08 Apr 2008 01:01 AM (UTC)
Message
Quote:
Well, actually, I didn't do any of those. They're all parts of stock code.

Well, by "you" I meant the code, not you personally. :-)

It's quite possible that this compiled fine for Nick when he wrote it but gives you warnings due to different compiler versions etc.

Quote:
lua_bits.c:108: error: invalid operands to binary -

Well, since 'text' is now signed, you want 'p' to also be signed. I bet that is what the warning on line 79 is from:
for (p = text; isspace (*p); p++)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #29 on Tue 08 Apr 2008 06:29 AM (UTC)
Message
Did you search the forum for this error, about "differ in signedness"?

See this page:

http://www.gammon.com.au/forum/bbshowpost.php?id=8000&page=2

My response at the time was:


Anyway, the bits file is not really required yet - I didn't use it for the initial stuff, and so far have only used it in one place to "and" a room flag.

I would remove it from the makefile for now, and remove the reference to it in the lua_scripting.c file.


In other words, this function isn't required. I just copied it over from MUSHclient, and due to compiler differences you are getting the error.

Also see this post:

http://www.gammon.com.au/forum/bbshowpost.php?id=8343

I also suggested there simply removing the bit_tonumber function as it isn't required, and we are wasting time fixing something that isn't actually used.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


93,338 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.