The discussion continued in a follow-up article I posted a bit later. Check out those two postings, as well as the comments, for the full discussion. In the end, I used a suggested approach of encoding the length of each line (the number of characters to print as a centered string) in ASCII, so an ‘A’ represented one, ‘B’ would be two, and so on. To convert ASCII to the values needed, the program would do a subtract 64:
On May 30, Sebastian T posted a new comment to that article with a suggestion that would reduce this program’s 64-byte size to 61 by getting rid of the “-64” bytes:
It would be nice to get rid of the “-64” part after the ASC() function, as this would save another 3 bytes, reducing the program size from 64 to 61 bytes.
All you have to do is to replace the characters inside the string with lower ASCII values just as needed, like &H01, &H03, &H05 and so on.
– Sebastian T. (5/30/2022)
Indeed, if instead of having “A”, “B”, “C”, etc. you could put in the raw bytes of 0, 1 and 2, that subtraction would not be needed. It is possible to alter BASIC programs to do this, but they create programs that are impossible for a user to type in from a listing. (I experimented with such a trick when I was working on a BASIC Pac-Man program.)
Or so I thought. Sebastian continued with a very clever approach/solution to typing in an un-typeable program:
You cannot use the keyboard to edit the string in this way, but I did write some self-modifying code that replaced the characters directly in program memory. After this, you can erase the extra code and you are left with a fully functional version that is 61 bytes long.
– Sebastian T. (5/30/2022)
What an interesting approach! Provide a fully typeable BASIC program which contains self-modifying code. Run the routine that self-modifies, then delete the self-modifying routine and save out the final program. Here is Sabastian’s example:
0 FORC=1TO14:W=ASC(MID$(“ACEGCGKOEKQWCC”,C)):PRINTTAB(16-W/2)STRING$(W,42):NEXT
10 ‘
20 ‘FIND FIRST STRING IN THE BASIC PROGRAM MEMORY AND HACK IT!
30 S=PEEK(25)256+PEEK(26) ‘START OF BASIC CODE IN MEMORY
40 E=PEEK(27)256+PEEK(28) ‘END OF BASIC CODE IN MEMORY
50 FOR A=S TO E
60 IF F THEN READ V : IF V<0 THEN END ELSE POKE A,V
70 IF PEEK(A)=34 THEN F=-1 ‘TOGGLE FLAG UPON REACHING THE FIRST QUOTATION MARK
80 NEXT A
90 DATA 1,3,5,7,3,7,11,15,5,11,17,23,3,3,-1
Sebastian concludes:
Run it once, then do a DEL 10-90. Run it again to verify it still fulfills the original task, and it does!
Some comments:
1) All tests done in XROAR 1.0.1 emulating a COCO 1 with 32k RAM.
2) I removed the “-64” before modifying the string, but you can also do it afterwards, even though the EDIT function will behave a bit funny while skipping over the non-printable characters in the string constant, but it works. I tested both ways.
3) If one of the characters had been 0 or 34 (quotation mark) this would have not worked. But this was not the case, so I got away with this. I’m not sure if there are other forbidden characters to consider, if somebody knows about this please comment.
4) In order to make sure this was still a valid program, I CSAVE’d it in a virtual cassette file, did a cold restart and reloaded the saved program. It works!
5) If you LIST the program, you’ll see a supposedly empty string inside the MID$() function, however it is not empty! I wrote a small memory monitor to verify this.
6) RENUM function won’t work now, though.
In summary, this trickery allows reduction of the final program size from 64 to 61 bytes.
Best regards!
– Sebastian T. (5/30/2022)
What an interesting approach. One can now type in a longer BASIC program, run it, DELete some lines, then end up with a smaller final program.
For BASIC programmers who used modified code for things like this, I suppose they were doing something like this. There would be a master program that could be edited and worked on, with routines at the end to modify strings and such, and then after the modification was ran, a second copy would be saved that could not be easily edited later.
And now we have a two-step way of creating a 61 byte version of that program.
I recently had a request on Fiverr to try to shaper up an out-of-focus video. I thought I might be able to do it using Topaz Labs Video Enhance AI. After several attempts, I concluded that this was not the right tool for the job. While it did have the ability to sharpen video, even on the highest settings it was not sufficient.
Instead, Ida at Topaz Labs support suggested converting the video in to individual images and processing them through their Topaz Labs Sharpen AI product. After a number of attempts to convert the video to individual images, I ended up using the open source FFmpeg program.
Convert movie to images
Using the option “-i” to specify the input video file, and “-vf” for the video filter with the options “fps” for how many frames per second to process and finally the output filename format.
For fps, if you want to capture every frame of the video, set this to the frames per second of the video file. In this example, the original video was 25 frames per section:
ffmpeg.exe -i VIDEO.MP4 -vf fps=25 out%d.png
For the output filename, you can use C printf-style variables such as %d so it knows where to place the number in the filename. Above, that would produce “out1.png”, “out2.png”, and so on.
Once you have all the frame images, they can be imported in to Sharpen AI and processed. This will produce new output filenames adding “-SharpenAI-Focus” or similar to the filename. You can then reassemble those individual images back in to a movie.
Convert images to movie
The option “-framerate” is used to generate that many frames per second in the new movie file. It should match the -fps value used above.
“-i” is used to tell FFmpeg what filenames to look for. It will also use the C printf-style parameters. Since Sharpen AI takes “out1.png” and creates a new file called “out1-SharpenAI-Focus.png” (when using the focus mode), I needed to match that filename.
The first video I created would not play, and I found setting “-pix_fmt” would make a playable MP4 file.
2022-06-09 – Added link to ExifTool source code that parses these sections. ExifTool command line example. Updated output of parser showing the MakerNotes fields. Adding crappy brute force C test code. Added hex dump screen shots of the sections.
*** WORK-IN-PROGRESS ***
I am posting this now in case it helps someone else who is trying to figure this out. My goal is to be able to modify a video recorded in Bullet Time mode to appear as a normal 360 video file. I just need to figure out what bytes to zap in the file…
It contains a Python script that parses the .insv files to export accelerometer and exposure data. This gave me a good starting point for exploring the .insv file format.
From there, searches led me to the ExifTool by Phil Harvey, which has support for parsing .insv files. Here is the parsing code:
The trailer is a series of (up to seven?) entries containing a 2-byte ID followed by a 4-byte offset. I am unsure if the entries are fixed, or if they can be terminated by 0x0000 / 0x00000000 entries if not all segments appear.
.insv file contents.
Segments defined in the Github Python script include:
Parsing begins at offset -78 by reading the 2-byte ID and 4-byte Size. The data for that ID will be located Size bytes earlier in the file. Data parsers for each segment seek there and begin parsing.
ExifTool
I have now found that ExifTool can be used to display these items. It does not show the Trailer information by default, but here is a command that displays it in .json format:
exiftool -ee -G -s -b -j -a -T filename.insv
Maker Notes – ID 0x0101
WORK-IN-PROGRESS: The “maker notes” section appears to use a byte for the type of data, then a byte for the length of that data segment. Some of the bytes appear to be (QuickTime::INSV_MakerNotes)
Hex Dec Description
--- --- -----------
0x0A 10 Serial Number ("IXSE42xxxxxxxx")
0x12 18 Camera Model ("Insta260 ONE X2")
0x1A 26 Firmware Version ("v1.0.51_build1")
0x2A 42 ? Parameters ?
NOTE: It appears that this section (0x0101) may be hard-coded to only have four entries, and the parser just reads four entries and stops. I was expecting some kind of record size or end of record marker, but looking at the ExifTool source shows it just does a for/next loop of 0-3.
Serial Number
Model
Firmware
Parameters
A simple parser I wrote in C can parse out some of these, then it gets lost at the binary data, so there is more to it than just that:
Magic Phrase: 8db42d694ccc418790edff439fe026bf
Good file.
0x0101 0x0000073a - Maker Notes
-------------------------------------------------------------------------------
Maker Notes - offset -1928
-------------------------------------------------------------------------------
Type: 0x0a (10) - SerialNumber
Length: 0x0e (14)
Data: 49 58 53 45 34 32 xx xx xx xx xx xx xx xx (edited out)
Text: IXSE42xxxxxxxx (edited out)
Type: 0x12 (18) - Model
Length: 0x0f (15)
Data: 49 6e 73 74 61 33 36 30 20 4f 4e 45 20 58 32
Text: Insta360 ONE X2
Type: 0x1a (26) - Firmware
Length: 0x0e (14)
Data: 76 31 2e 30 2e 35 31 5f 62 75 69 6c 64 31
Text: v1.0.51_build12
Type: 0x2a (42) - Parameters
Length: 0x71 (113)
Data: 32 5f 31 34 37 33 2e 36 38 30 5f 31 35 32 32 2e
39 39 30 5f 31 35 34 34 2e 35 36 30 5f 30 2e 30
33 32 5f 2d 31 2e 30 39 33 5f 2d 31 37 38 2e 30
31 30 5f 31 34 37 35 2e 34 35 30 5f 34 35 35 34
2e 30 39 30 5f 31 35 30 33 2e 36 32 30 5f 2d 30
2e 30 32 39 5f 2d 31 2e 32 39 37 5f 2d 30 2e 37
36 38 5f 36 30 38 30 5f 33 30 34 30 5f 33 31 31
33
Text: 2_1473.680_1522.990_1544.560_0.032_-1.093_-178.010_1475.450_4554.090_1503.620_-0.029_-1.297_-0.768_6080_3040_3113
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x00000000 - Unknown
0x0000 0x000f16f4 - Unknown
More work to be done on this part…
Accelerometer Data – ID 0x0300
TODO
Exposure Data – ID 0x0400
TODO
Timestamps – ID 0x0600
TODO
GPS Data – ID 0x0700
TODO
To be continued…
Crappy Brute-Force C Parsing Test Code
/*--------------------------------------------------------------------------*/
// .insv parser test.
//
// 2022-06-08 0.00 allenh - Initial brute-force version.
// 2022-06-09 0.01 allenh - Code cleanup, more defines.
/*--------------------------------------------------------------------------*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h> // for memset()
#include <stdint.h>
#include <stdbool.h>
#define FILENAME "VID_20220607_102410_00_322.insv"
//#define FILENAME "VID_20220607_104109_00_323.insv"
/*--------------------------------------------------------------------------*/
// Defines / Constants / Enums
/*--------------------------------------------------------------------------*/
#define TRAILER_OFFSET -78
#define TRAILER_SIZE 42
#define MAGIC_PHRASE_OFFSET -32
#define MAGIC_PHRASE_SIZE 32
#define MAGIC_PHRASE_STRING "8db42d694ccc418790edff439fe026bf"
enum
{
HID_MAKER_NOTES = 0x0101,
HID_ACCELEROMETER = 0x0300,
HID_EXPOSURE = 0x0400,
HID_TIMESTAMPS = 0x0600,
HID_GPS = 0x0700
} HidEnum;
enum
{
MAKER_NOTES_SERIALNUMBER = 0x0a,
MAKER_NOTES_MODEL = 0x12,
MAKER_NOTES_FIRMWARE = 0x1a,
MAKER_NOTES_PARAMTERS = 0x2a
} MakeNotesEnum;
/*--------------------------------------------------------------------------*/
// Prototypes
/*--------------------------------------------------------------------------*/
bool checkForMagicPhrase (FILE *fp);
bool parseTrailer (FILE *fp);
bool parseMakerNotes (FILE *fp, long int offset);
const char *getHidString (unsigned int hid);
const char *getMakerNotesString (unsigned int id);
uint32_t freadU32 (FILE *fp);
uint16_t freadU16 (FILE *fp);
uint8_t freadU8 (FILE *fp);
void hexDump (void *ptr, size_t size);
/*--------------------------------------------------------------------------*/
// Main
/*--------------------------------------------------------------------------*/
int main (int argc, char **argv)
{
(void)argc;
(void)argv;
FILE *fp = NULL;
fp = fopen (FILENAME, "rb");
if (fp != NULL)
{
if (checkForMagicPhrase (fp) == true)
{
printf ("Good file.\n");
parseTrailer (fp);
}
}
else
{
perror ("Unable to open");
}
fclose (fp);
return errno;
}
/*--------------------------------------------------------------------------*/
// Functions
/*--------------------------------------------------------------------------*/
/*--------------------------------------------------------------------------*/
// Check for the 32-byte magic phrase at the end of the file.
/*--------------------------------------------------------------------------*/
bool checkForMagicPhrase (FILE *fp)
{
bool status = false;
if (fp != NULL)
{
int retVal = 0;
retVal = fseek (fp, MAGIC_PHRASE_OFFSET, SEEK_END);
if (retVal == 0) // If successful, the function returns zero.
{
size_t bytesRead = 0;
char buffer[MAGIC_PHRASE_SIZE+1];
memset (buffer, 0x0, sizeof(buffer));
bytesRead = fread (buffer, sizeof(buffer[0]), MAGIC_PHRASE_SIZE, fp);
if (bytesRead == MAGIC_PHRASE_SIZE)
{
if (strncmp (buffer, MAGIC_PHRASE_STRING, sizeof(buffer)) == 0)
{
// Match.
printf ("Magic Phrase: %s\n", buffer);
status = true;
}
}
}
}
return status;
}
/*--------------------------------------------------------------------------*/
// Parse Trailer.
/*--------------------------------------------------------------------------*/
bool parseTrailer (FILE *fp)
{
bool status = false;
if (fp != NULL)
{
int retVal = 0;
long int offset = 0;
offset = TRAILER_OFFSET;
while (offset < TRAILER_OFFSET+TRAILER_SIZE)
{
retVal = fseek (fp, offset, SEEK_END);
if (retVal == 0)
{
uint16_t hid = 0;
uint32_t size = 0;
hid = freadU16 (fp);
size = freadU32 (fp);
printf ("0x%04x 0x%08x - %s\n", hid, size, getHidString (hid));
switch (hid)
{
case HID_MAKER_NOTES:
parseMakerNotes (fp, offset-size);
break;
}
offset = offset + sizeof(uint16_t) + sizeof(uint32_t);
}
}
}
return status;
}
/*--------------------------------------------------------------------------*/
// Parse INSV_MakerNotes section.
/*--------------------------------------------------------------------------*/
bool parseMakerNotes (FILE *fp, long int offset)
{
bool status = false;
uint8_t type = 0;
uint8_t length = 0;
size_t bytesRead = 0;
uint8_t buffer[255];
printf ("-------------------------------------------------------------------------------\n");
printf ("Maker Notes - offset %ld\n", offset);
printf ("-------------------------------------------------------------------------------\n");
// There can be only four?
for (int entryNumber=0; entryNumber < 4; entryNumber++)
{
if (offset >= TRAILER_OFFSET) // Hack.
{
break;
}
fseek (fp, offset, SEEK_END);
type = freadU8 (fp);
length = freadU8 (fp);
printf (" Type: 0x%02x (%u) - %s\n", type, type, getMakerNotesString (type));
printf ("Length: 0x%02x (%u)\n", length, length);
bytesRead = fread (buffer, sizeof(uint8_t), length, fp);
if (bytesRead == length)
{
printf (" Data: ");
hexDump (buffer, length);
printf (" Text: %s\n", buffer);
}
offset = offset + length + sizeof(uint8_t) + sizeof(uint8_t);
printf ("\n");
}
return status;
}
/*--------------------------------------------------------------------------*/
// Return pointer to string for Hid.
/*--------------------------------------------------------------------------*/
const char *getHidString (unsigned int hid)
{
const char *ptr = "Unknown";
switch (hid)
{
case HID_MAKER_NOTES:
ptr = "Maker Notes";
break;
case HID_ACCELEROMETER:
ptr = "Accelerometer";
break;
case HID_EXPOSURE:
ptr = "Exposure";
break;
case HID_TIMESTAMPS:
ptr = "Timestamps";
break;
case HID_GPS:
ptr = "GPS";
break;
}
return ptr;
}
/*--------------------------------------------------------------------------*/
// Return pointer to string for MakerNotes ID.
/*--------------------------------------------------------------------------*/
const char *getMakerNotesString (unsigned int id)
{
const char *ptr = "Unknown";
switch (id)
{
case MAKER_NOTES_SERIALNUMBER:
ptr = "SerialNumber";
break;
case MAKER_NOTES_MODEL:
ptr = "Model";
break;
case MAKER_NOTES_FIRMWARE:
ptr = "Firmware";
break;
case MAKER_NOTES_PARAMTERS:
ptr = "Parameters";
break;
}
return ptr;
}
/*--------------------------------------------------------------------------*/
// Read U32, convert and return.
/*--------------------------------------------------------------------------*/
uint32_t freadU32 (FILE *fp)
{
uint32_t val = 0;
uint8_t a,b,c,d;
a = freadU8 (fp);
b = freadU8 (fp);
c = freadU8 (fp);
d = freadU8 (fp);
val = (a) | (b << 8) | (c << 16) | (d << 24);
return val;
}
/*--------------------------------------------------------------------------*/
// Read U16, convert and return.
/*--------------------------------------------------------------------------*/
uint16_t freadU16 (FILE *fp)
{
uint16_t val = 0;
uint8_t msb = 0;
uint8_t lsb = 0;
msb = freadU8 (fp);
lsb = freadU8 (fp);
val = (msb << 8) | (lsb);
return val;
}
/*--------------------------------------------------------------------------*/
// Read U8.
/*--------------------------------------------------------------------------*/
uint8_t freadU8 (FILE *fp)
{
uint8_t val = 0;
val = fgetc (fp);
return val;
}
/*--------------------------------------------------------------------------*/
// Dump bytes as HEX, with a tab at the start of lines after the first.
/*--------------------------------------------------------------------------*/
void hexDump (void *ptr, size_t size)
{
int col = 1;
if (ptr != NULL)
{
for (int idx=0; idx<size; idx++)
{
printf ("%02x ", ((uint8_t*)ptr)[idx]);
if ((col % 16) == 0)
{
printf ("\n\t");
col = 0;
}
col++;
}
printf ("\n");
}
}
// End of main.c
I am posting this in case someone else is doing the same searches I am.
I am trying to find details on the Insta360 ONE X2 file formats for photos (.insp) and videos (.insv). They contain meta-data I’d like to be able and parse to determine what kind of files they are. Going by filename is not enough.Th
This came up again today when someone contacted me with a ONE X2 video that was recorded in Bullet Time mode. It was not meant to be, but because the file is saved that way, the Insta360 Studio program will not allow reframing/editing the video.
Insta360 support (via app chat) has an auto responder if you ask about changing Bullet Time files to normal videos, so they have a way to do it — if you send them the files.
In the case of Bullet Time, is is recorded at 100 fps in 3K mode. It stores both lens videos in the same file. This is the same format used when recording normal 360 video at 3K / 100 fps. It appears only the meta-data is making the file appear one way or the other.
When you slow down video by increasing the time between each frame, you get chunky video. To get smooth slow motion, the video is recorded at a high frame rate. For example, instead of a normal 30 frames per second like US TV, the video might be recorded at 120 frames per second. Now you can slow it down to 1/4 speed and still be displaying 30 frames per second.
But what if you have footage that was not shot at a high frame rate and you still want smooth slow motion?
AI video processing can take care of this. Below is a short clip I recorded.
On the left is the original video slowed down in a video editor. Notice the pauses between each frame.
On the right is the same video, processed by Topaz Labs Video Enhance AI, where it CREATES frames in between the ones in the original video! Check it out then I’ll add some more details…
What did you notice? Did it look good?
Watch it again, and this time, focus on the wheels of the car that passes on the left side. Also pay attention to the lettering on the side of the white van on the right.
Notice the defects? The AI does pretty amazing things, but still has artifacts that let us know it’s being processed.
2025-04-23 – adding sections for the X5 and GPS remote, and some placeholder sections in case anyone contributes.
If you have found any bugs, please leave a comment with the version and details and I will add them to this list. As workarounds are discovered, I will update this list.
As a new version of firmware is released, these bugs will be re-tested. When they work for some, and not for others, a note will be added to that effect.
GPS Action Remote
1.0.2.10 (unknown release date, checked on 4/23/2025)
TBA – if anyone contributes.
X5
2025-04-22 – v1.0.0
TBA
2025-04-24 – v1.0.2
TBA
Legacy Devices
X4
TBA – if anyone contributes.
X3
TBA – if anyone contributes.
ONE X2
2022-04-26 – v1.0.51
Open WiFi – a poorly implemented WiFi system has the camera broadcast itself as a WiFi hotspot to anyone within range, and allows users that know the default WiFi password all X2 cameras have to access and download any files on the memory card from a web browser… or worse. (Suggested by commenter, yt)
Screen Auto Sleep – 5s timeout regardless of settings. Sometimes “1min” and “Never” appear to work, but screen keeps reverting back to around 5s before going black. (Originally reported in 1.0.41_build1)
USB-c connection to iPad Pro unstable. Currently is not allowing files to be downloaded. Tested with an iPad Pro (11-inch) (3rd generation). (Reported in 1.0.51)
GPS Smart Remote
1.0.8.2
“Camera’s remaining battery” always shows empty, regardless of charge level of camera. Battery indicator for GPS Smart Remote seems to be working.
5-20-2022: IMDB, blogs and other sites with comments all seem to have folks reporting that this was called “Project Blue Book” when they saw it. I have also found one reference to it being called that for the United Kingdom release. If anyone can find proof it was ever called that in the U.K. or anywhere else, please leave a comment. Until then, I guess this is just a mass false memory/Mandela Effect…
I have memories of watching a late-1970s TV series called Project Blue Book. This would have been how I first learned about the government’s actual investigation in to U.F.O.s. Here is the wikipedia entry about the real government project:
Not too long ago I saw something about a new TV series called Project Blue Book and I had wondered if it was a remake/reboot of the 1970s one. I have yet to see any of the episodes, but here is the wikipedia entry about this TV series:
I have certainly heard much more about the real Project Blue Book over the years, thanks to seeing the occasional show about U.F.O.s. When it was brought up, I always through about that 1970s TV series.
As far as the series goes, I don’t remember much about the actual episodes, except it seemed they were always debunked by the end of the show. I remember one that shared the story of how a U.F.O. blasted the hood of a car. By the end of the series, it was declared a hoax, and they showed that the burn marks on the hood had been made with a road flare or something like that.
So why this post now?
The other day, I saw a reference on Mastadon to “project bluebeam” — whatever that was. I wanted to respond with a link to the TV series for Project Blue Book, and make a reference to “liking the original project better.”
There is indeed a wikipedia entry for the TV series I was remembering, except it was listed as Project U.F.O. — which I had never heard of. It did include a note:
Also known as
Project Blue Book (in some countries)
-wikipedia entry for Project U.F.O.
…and the wikipedia page for “Project Blue Book (TV Series)” goes to a page about the new series.
Apparently Project U.F.O. must have been used outside of the U.S.A. Or not.
A quick YouTube search led me to a copy of the show, recorded over the air from a Chicago, Illinois TV station:
As soon as the video began, I remembered that opening sentence about Ezekial and the wheel. (You know, that passage in the bible about him seeing a U.F.O. We can discuss the passage in the bible that discusses the unicorn sometime, as well…)
This informed me that at least in Chicago, the show aired as Project U.F.O. (and I noticed the intro did not make any reference to Project Blue Book).
Asking around (online), I found folks who grew up on other parts of the U.S.A. that also saw it as Project Blue Book.
I am posting this here to see if any of my U.S.A. readers were old enough to have seen this show, and could tell me what it was called where you saw it (and please let me know where you saw it).
It’s interesting thinking about a show airing in different regions using different titles.
UPDATE: Looks like others saw it air at Project Blue Book. Look at he IMDB reviews…
The top article on this site for the past 5 or so years has been a simple C tidbit about splitting 16-bit values in to 8-bit values. Because of this, I continue to drop small C things here in case they might help when someone stumbles upon them.
Today, I’ll mention some redundant, useless code I always try to add.,,
I seem to recall that older specifications for the C programming language did not guarantee variables would be initialized to 0. I am not even sure if the current specification defines this, since one of the compilers I use at work has a specific proprietary override to enable this behavior.
You might find that this code prints non-zero on certain systems:
int i;
printf ("i = %d\n", i);
Likewise, trying to print a buffer that has not been initialized might produce non-empty data:
Because of this, it’s a good habit to always initialize variables with at least something:
int i=0;
char message[42];
...
memset (message, 0x0, sizeof(message));
Likewise, when setting variables in code, it is also a good idea to always set an expected result and NOT rely on any previous initialization. For example:
int result = -1;
if (something == 1)
{
result = 10;
}
else if (something == 2)
{
result = 42;
}
else
{
result = -1;
}
Above, you can clearly see that in the case none of the something values are met, it defaults to setting “result” to the same value it was just initialized to.
This is just redundant, wasteful code.
And you should always do it, unless you absolutely positively need those extra bytes of code space.
It is quite possible that at some point this code could be copy/pasted elsewhere, without the initialization. On first compile, the coder sees the undeclared “result” and just adds “int result;” at the top of the function. If the final else with “result = -1;” wasn’t there, the results could be unexpected.
The reverse of this is also true. If you know you are coding so you ALWAYS return a value and never rely on initialized defaults, it would be safe to just do “int result;” at the top of this code. But, many modern compilers will warn you of “possibly initialized variables.”
Because of this, I always try to initialize any variable (sometimes to a value I know it won’t ever use, to aid in debugging — “why did I suddenly get 42 back from this function? Oh, my code must not be running…”).
And I always try to have a redundant default “else” or whatever to set it, instead of relying on “always try.”
