Odd illegal digit errors

Printable View

07-22-2012
ulillillia

Odd illegal digit errors

This is an error I've never seen until now and it doesn't make sense to me. Why am I getting it on this line:

Code:

SceneryXOffset[LoopCount] = 099385ll; SceneryOffsetStart[LoopCount] = 0; SceneryOffsetWidth[LoopCount] = 86; LoopCount++; // straw huts (3)

I'm not providing extra lines as I have several such closely related things together. The ll (LL) is there for a reason - it's intended to be a 64-bit integer. The others are just regular 32-bit integers. This one line alone has 3 errors, of which I don't get:

Code:

1>.\Platform Masters.c(14616) : error C2041: illegal digit '9' for base '8' 1>.\Platform Masters.c(14616) : error C2041: illegal digit '9' for base '8' 1>.\Platform Masters.c(14616) : error C2041: illegal digit '8' for base '8'

I've used lots of 64-bit integers without problems, so what's going on? How come the similar lines directly below have no problems?

Code:

SceneryXOffset[LoopCount] = 654373ll; SceneryOffsetStart[LoopCount] = 0; SceneryOffsetWidth[LoopCount] = 86; LoopCount++; SceneryXOffset[LoopCount] = 816026ll; SceneryOffsetStart[LoopCount] = 0; SceneryOffsetWidth[LoopCount] = 86; LoopCount++; ... // plus 21 more grouped up like this, none of which have any problems

Thinking the leading zero is the culprit, how come this line works just fine, found 37 lines below the one without the error when the one being flagged does produce an error?

Code:

SceneryXOffset[LoopCount] = 051302ll; SceneryOffsetStart[LoopCount] = 0; SceneryOffsetWidth[LoopCount] = 86; LoopCount++;

Any ideas? Thanks.
07-22-2012
oogabooga

Starting a number with a zero indicates that it's in octal, in which case you can't have digits above 7 in it.
07-22-2012
Matticus

Values starting with zero are, I believe, considered octal values (base-8).

Therefore, seeing '9' and '8' in a number that only expects digits 0 - 7 will produce errors.

Notice that the other values that start with zero and don't produce errors (my guess is all of them in addition to the one shown) because they're all valid numbers in octal.
07-22-2012
ulillillia

Oh, I wasn't aware of octal being in programming. I knew that putting an x after the 0 indicates hexadecimal, of which I've used plenty of times before as expected so I avoided that and just kept the 6-digit temporary random position. I only knew of both decimal and hexadecimal being present. Throwing a 1 in the front certainly gets rid of the errors though. I guess I'll have to have my temporary offsets 1 million CU more to the right, of which I'll fill in exact positions later as I form the terrain. Thanks for the info on that.
07-22-2012
ulillillia

@Matticus I wasn't after using octal, I was only intending on decimal, for setting temporary random values from 0 to 999,999 with 6 digits always present (which meant keeping the leading zeros). I have reasons for this.
07-23-2012
iMalc

Quote:

Originally Posted by ulillillia

@Matticus I wasn't after using octal, I was only intending on decimal, for setting temporary random values from 0 to 999,999 with 6 digits always present (which meant keeping the leading zeros). I have reasons for this.

That makes no sense whatsoever. Your "reasons" are based on wrong assumptions. There's no such thing as keeping leading zeros when assigning to an integer.
An integer stores whole numbers. Having 042, 0042, or 00042 apples for example, is nonsense; You'd still just have 42 apples.

Remove the leading zero and it will be fine. Leading zeros are only an artifact of how you choose to print them when you convert them to text.
07-23-2012
ulillillia

You don't know what I'm doing. I generated the numbers randomly and from formatting I had and copying and pasting, I had the leading zeros. Of course, this isn't everything - the full details are being kept hidden from the public. The issue is solved and thus this thread can be closed or locked.
07-23-2012
Matticus

It's a basic programming ability to convert data from one form to another before processing.

Too bad all the details have to be kept hidden ... I was kind of hoping for some more. Back to the conspiracy files.
07-23-2012
iMalc

Quote:

Originally Posted by ulillillia

You don't know what I'm doing. I generated the numbers randomly and from formatting I had and copying and pasting, I had the leading zeros. Of course, this isn't everything - the full details are being kept hidden from the public. The issue is solved and thus this thread can be closed or locked.

That's not a reason for "keeping" them, that's merely a reason that they'd unfortunately be there to begin with.
Your statement about adding "temporary offsets 1 million CU more to the right" to me indicated this was actually about a misunderstanding of integer variables.
Seriously, don't worry about it though. You weren't the first person to have that misunderstanding, and you wont be the last. Most of us have posted questions that would make us facepalm looking back on them now. Learning from it and moving on is all that matters.

They don't really close threads on request around here. The community tends to decide when all important points have been covered off and then the thread is naturally left to gather dust.
07-23-2012
Salem

> 1>.\Platform Masters.c(14616) : error C2041: illegal digit '9' for base '8'
..
> SceneryXOffset[LoopCount] = 099385ll; SceneryOffsetStart[LoopCount] = 0; SceneryOffsetWidth[LoopCount] = 86; LoopCount++; // straw huts (3)
Please tell me you don't have a source file with 10K+++ lines to initialise a big array, and you only "reason" for leading zeros is to make the code look nicely formatted.

Use spaces if you want pretty code

Code:

array[n++] = 1234; array[n++] = 34; array[n++] = 4;

This should be 20 lines of source code and a data file.

> I guess I'll have to have my temporary offsets 1 million CU more to the right
Another reason for a data file is that you seem to be autogenerating this "code" from some scenery editor to begin with.

Try thinking about the whole data flow of your program, instead of introducing random hackery to "solve" apparent non-issues.
07-24-2012
ulillillia

When I have a group of variables that are very closely related that are intended to be arranged in a table, I format the lines like an Excel spreadsheet would. It makes it much easier for me to read. Throw in comments so I know where the starts of various sections are, and I have no trouble finding what I need.

I needed fillers or I'd get "integer division by 0" errors (if width was 0) or I could never find the object in question to see if it draws properly because the values aren't initiated or the drawing span goes outside the image's bounds so I had to put something there so I just generated some random position numbers as placeholders - the others are set directly with some randomization (true randomization would make the object draw incorrectly or not draw at all). Like stated before, I had no idea that a 0 starting a number led to octal. I knew that adding an x after the 0 meant hexadecimal, of which I didn't want, so I ensured that I avoided that. Thinking that 004182 was going to be treated as 004182, I kept the leading zeros. As I was about to preview what Barugan Islands was going to look like, I got those errors and they didn't make any sense which is why I asked.

The source file is just passing 35,000 lines and the setting of positions occupies a total of about 3000 of those. It's high because each of about 14 different environments consume these and I use loops as much as I can. I use loops when I want to change the density by spacing the actual positions closer. Being generated in Excel, it's very quick to transfer and modify them as needed with some quick word of Wordpad's "replace" feature. Besides, if I move the positions and widths to another file, I only get errors stating of that variable being an "undeclared identifier".