The number should be the number of the line with the problem.
Yeah, line 6 in a 2 line script. 
FWIW, that can happen if the file is not actually in plain ASCII text format.
Yeah, but they all are preset functions. If I try changing them beyond anything, don't they just fail to work, since CHDK functions are designed to only output specific values? So for example, if set_mode(1) is video mode, set_mode(2) is auto mode, and set_mode(3) is sports mode, if there is a certain hidden mode, if I use set_mode(4), it won't actually trigger that mode since CHDK doesn't have that value to inject into the camera, right?
First, there is no set_mode. If you mean set_capture_mode, then yes, only values known to be valid on your camera (which might included undocumented modes if they are known to work) will do anything, because that function works with CHDK generic values that need to be mapped to camera-specific Canon values, and the mapping is defined per-port based (in theory) on the ones that are known to work. However, CHDK also provides
set_capture_mode_canon which accepts arbitrary values in the native numbering system.
In any case, it's extremely unlikely that any Canon modes not identified in stubs_entry.S will do anything, aside from possibly crashing.
For example, these Unused Paint Jobs were found by me, because when I extracted the ASSETS.DAT data file, which contained the game data files, there was a txt file which was by the devs that signified that there was supposed to be an Enamel paint job type, which isn't in the game, and I found it, among another two paint types which aren't even documented.
Well then, firmware reverse engineering is conceptually the same thing, you look for clues and try stuff. You won't find text files, but there are a lot of debug messages and known function names (see the funcs_by_name.csv in the platform / sub directory of your port). However, aside from guessing what
eventprocs might do based on name, you generally need to be able to understand firmware code a bit do much useful. Even for eventprocs, it's very helpful to be able to look at the code to get an idea of what kind of parameters they expect and confirm they actually might do something like the name suggests.
Is there a chance I can brick my camera by directly writing to the addresses?
Short answer: Yes, there's a chance.
Longer answer: You'd have to be pretty determined or very unlucky to brick your camera with poke, but we can't promise you won't damage your camera. Your odds of avoiding damage are better if your experiments are informed by analyzing the firmware, rather than blindly trying stuff.
Is there perhaps a tutorial where I can see how to do this?
Not really. You need a working knowledge of CHDK, the camera firmware and the related programming and reverse engineering concepts, and after that, you don't need a tutorial
Is there actual information for the S3IS addresses for all the things CHDK uses? I mean, CHDK itself needs to know which address to write where when I override the shutter speed, or ISO, or Aperture. set_capture_mode() is a function if I understand correctly that CHDK uses to inject a custom value into the memory address of the camera to do this.
As Blackhole said, the functions CHDK uses are in the CHDK source, mostly in the stubs_entry.S and stubs_entry_2.s files for your port. Note most CHDK functionality involves setting propcases or calling firmware functions rather than directly writing memory, although that's also done in a few cases. The Canon firmware is quite complicated, it's rare for significant functionality to be controlled by a single variable.
If I could emulate the S3IS firmware on my computer, like what I do with the PS2 games, I could use Cheat Engine, see which address changes when a certain mode is changed, and directly write to it, and then when I know what to write where, I'd be able to use Poke, and simply write to that address, however, it seems you need to know how the firmware itself works before doing anything.
It is actually
possible to run Canon firmware for some cameras in an emulator, but the current code does not support S3IS, so you'd have to implement that first, which is a significant reverse engineering + coding project in it's own right. In any case, it doesn't help much with shooting-related code, since emulating all the hardware would be very difficult.
If only these sprites were of any use. 
The icons being present doesn't mean the functionality is present. Those particular icons may also be used in review mode when a file matches relevant naming convention or has corresponding exif fields.
