Problem with < comparisons in if(): string vs number

[Austin Holloway]

Hi LDMuddies. I'm a newbie here, starting up a mud on my Linux machine in my office.

Everything was going fine then one day I started seeing errors like this:

Arguments to < don't match: string vs number
program: obj/player.c, object: obj/player#0 line 958

The code in player.c is simple:

if( j < i )

Where both are type int.  I've seen the same error in other bits of code too.  I can change every comparison to to_int(j) < to_int(i) and that works just spiffy, but I should not have to change all million comparisons in all objects like this.

The only change between working and not working was me installing duplicati for backups. I removed duplicati, reinstalled gcc and the problem is still there.

I would appreciate anyone's help on this as I am dead in the water.

Thanks,

Austin

[Stephan Weinberger]

Hi Austin,

Can you give a little more context (i.e. a relevant section of your code)?

Reinstalling gcc will not change anything, as LPC programs are not compiled by gcc, but by ldmud (since you're writing in ldmud-talk I presume it is a LPC program running in ldmud).

I dont know how duplicati works, but I can't think of any way how backup software could interfere with ldmud.

Also: what version of ldmud are you using? That error message is not what any recent version would write. From what I can see on github it would be "bad argument 2 to <" since at least 9 years.

cya,
  Stephan

--
You received this message because you are subscribed to the Google Groups "LDMud Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldmud-talk+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/9a56dcca-41bb-40d0-9436-36968d2daa08n%40googlegroups.com.

[Austin Holloway]

ldmud is 3.6.5.

Standard lpmud 2.4.5 mudlib.

I'm not sure if I can give you any more context.

[Stephan Weinberger]

Ok, I was a bit too quick and overlooked that error message in the source.


Well, more context by providing more than just a single line of code...
If j and i are really both ints then this should not happen. So I guess they are not.

Also note that LPC is a loosely typed language. If you don't specifically enable strict type checks (with "#pragma rtt_checks"), you can assign any value to any variable, regardless of how it is declared.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/61887a4a-9675-4022-b889-c978fa560546n%40googlegroups.com.

[Austin Holloway]

Here is a snippet of code that has the problem:

int withdraw(int wamount) {

    if( wamount <= 0 )
        return 0;

...

"Arguments to <= don't match: string vs number
program: obj/bank_obj.c, object: obj/bank_obj#89 line 82"

I understand type checks are off by default, and I have not enabled them. 

I removed gcc and build-essential to make sure there was no outside intervention.

>>Ok, I was a bit too quick and overlooked that error message in the source.

So does that mean the error message is in the source?  Where?

Austin

[Croft]

That means this function gets called with a string when it should be called with an integer.

You probably need to convert it with to_int() before you call the function.

To view this discussion on the web visit https://groups.google.com/d/msgid/ldmud-talk/8e8d7588-78fe-46cb-a98b-d14cd904a225n%40googlegroups.com.

[Zesstra]

On 10.04.22 01:52, Austin Holloway wrote:
> Here is a snippet of code that has the problem:
>
> int withdraw(int wamount) {
>
>     if( wamount <= 0 )
>         return 0;
> ...
>
> "Arguments to <= don't match: string vs number
> program: obj/bank_obj.c, object: obj/bank_obj#89 line 82"
>
> I understand type checks are off by default, and I have not enabled them.

In this case, the caller of withdraw() called it with wamount being a string,
not int (number). That is a rather classic situation in LPC which you can
either deal yourself with in each function or enable the runtime type checks.

A) runtime type checks:
set the pragma rtt_checks (and strong_types or strict_types)
#pragma rtt_checks,strong_types
This will likely cause problems in old code bases requiring some work, because
of wrong calls, wrong overrides etc. These are programming errors in any case,
but without the pragma they are not systematically checked and reported by the
driver.
For a migration period, you can use the warn_rtt_checks instead of rtt_checks.


B) check for correct types in your function
if (!intp(wammount))
raise_error("Wrong type for argument wamount.\n");
Since you basically have to check in every function receiving arguments
manually when not using rtt_checks this causes also some work in practice.

Bye,
Zesstra@MG
--
MorgenGrauen -
1 Welt, mehr als 200 Programmierer , mehr als 16000 Raeume,
viel mehr als 7000 unterschiedliche Figuren, 90 Quests, 13 Gilden,
ueber 5000 Waffen und Ruestungen, keine Umlaute und ein Haufen Verrueckter.
Existenz: mehr als 25 Jahre
http://mg.mud.de/

[Stephan Weinberger]

On 10.04.22 01:52, Austin Holloway wrote:

> Here is a snippet of code that has the problem:
>
>
> int withdraw(int wamount) {
>
>     if( wamount <= 0 )
>         return 0;
> ...
>
> "Arguments to <= don't match: string vs number
> program: obj/bank_obj.c, object: obj/bank_obj#89 line 82"

Then withdraw() was called with a string argument. LPC does *not*
prevent this by default, unless "#pragma strict_types" and/or "#pragma
rtt_checks" is active (the former only checks during compile-time, so it
will not catch call_other()s with a wrongly typed argument).

So you need to check/fix the part of the code where withdraw() is called
from.

In an existing codebase you can also set "#pragma warn_rtt_checks",
which will generate a warning if the wrong type is used but will not
abort execution like "#pragma rtt_checks" does.


I guess that you're calling withdraw() from a command the user entered,
like "withdraw 50 coins". That will be the string "50", which has to be
converted to an integer first, e.g. using to_int() or sscanf().

>
> >>Ok, I was a bit too quick and overlooked that error message in the
> source.
> So does that mean the error message is in the source?  Where?

That was just a correction to my initial reply that "this message is not
generated by current versions of ldmud". That was wrong - I just looked
in the wrong place.



cya
  Stephan