• Hanzito (unregistered)

    Ooh, nice one. I can almost feel the surge of embarassement. Nice twist on the "indented line that's not part of the else-branch" bug in C. But I'm sure there are tales of bugs caused by auto-indenting, too. I'm not saying it has to be in Python, but that would be likely candidate.

  • Tim Ward (unregistered)

    Duh. I spotted it instantly, a bog standard C gotcha.

  • RLB (unregistered)

    "Everyone's favorite trivial change: 8 and 9 are not octal digits."

  • (nodebb)

    Been there, done that. Well, assuming that "there" means "in Argle's position" and "that" means "looking at some unintentionally octal numbers inserted by a colleague".

    The date: some time in 1992 or so. The system: embedded firmware for a gas flow corrector(1).

    The UI is a small (2 lines of 20 or so characters) low-res LCD panel and a numeric keypad, with a lock operated by a Yale-style physical key to lock out changes. The display is, as a result, separated into pages, and the pages are organised into what I'll call "books", "chapters", and individual pages of a chapter. The books, chapters and pages are all numbered from zero, and chapters are numbered per book rather than overall, and pages are numbered within their chapter.

    So book 1, chapter 1, page 4 would be represented (in four digits) as 1104.

    The configuration pages in the version my colleague was working on suddenly stopped working in chapter 1 and beyond of the first book. Um. Book 0.

    He stared and stared at the code, just like Argle's colleagues did, then asked me if I had any ideas. Just like Argle, I spotted the octality of the preset integers (as opposed to strings of characters) straight away, and said, "Aren't those in octal?". He facepalmed and went away to fix it. It looked really pretty with all the leading zeroes so that the numbers looked like what was displayed, without nasty expensive string analysis, but it didn't work.

    (1) It measures gas flow (usually but not always natural gas, could also be steam) and calculates the amount of gas under some standard temperature and pressure (for steam, the mass in whatver unit takes your fancy).

    Addendum 2022-08-18 09:01: Um, 'The pages in the version my colleague was working on..." --> I don't actually remember which chapter was which any more.

  • kdgregory (unregistered)

    For me, it was taking a list of ISO-formatted dates ("2022-08-18") and turning it into a list with a global search-and-destroy that changed dashes to commas. Fortunately, I realized the mistake before it ever got out of my hands.

  • (nodebb)

    The real WTF is the programming language itself, interpreting leading 0's as 'this is octal'. Any non-numeric prefix for octals is better. Those where the days...

  • (nodebb)

    Basic first year stuff.... That people are employed (to use a given technology/tool/etc) and yet do not have this fundamental knowledge is a problem that far exceeds the software domain. I would have called a high-schooler (or even a middle schooler) to task for this!

    [Of course I am also evil, so: 000, 031, 055, 0101, 0175 you have been the appropriate values to put in the lookup table (without comments)....]

    PS: If you ever pulled an all nighter working in octal, than balanced your checkbook in the morning (yeah, remember when that was a thing) and accidently also did that in Octal; explaining to the bank, creditors, vendors why you bounced a bunch of checks is a futile exercise)

  • (nodebb) in reply to JanDoggen

    Octal is all - A HEX on those who group by bits of 4 (or by non-binary means - and no, this is not the trollybus garage)

  • James F (unregistered) in reply to JanDoggen

    It's a major mis-feature of C. However back in 1970 octal was considered the most useful way to represent binary numbers, so I guess this is why the C designers made it so easy to enter octal numbers. By 1980 hex had won out.

  • Hans (unregistered)

    Javascript also has this feature. I remember writing a date validation routine that used parseInt and worked fine for all test cases. And then blew up in august and september, months "08" and "09" ...

    Since then I always specify the radix (parseInt(somestring, 10))

  • Wyatt (unregistered)

    I've run into this in very recently where someone entered an IP address with a leading zero in one of the octets. 192.168.015.110 is not the same as 192.168.15.110.

  • Argle (unregistered)

    Quick follow-up: there seems to be a class of problems. that can only be solved by showing them to someone else. It's a perfectly common low-level WTF I think we all deal with. My late wife, a non-programmer, was occasionally forced to look at something I was stuck on that I was working on privately. The act of explaining usually did the trick for me to see what I was doing wrong.

  • Anon (unregistered)

    See, this is why syntax highlighting is so important.

  • tbo (unregistered) in reply to Argle

    You were married to a rubber duck?

  • (nodebb)

    Quite proud of myself for spotting the problem immediately ^^ But seriously, who TF thought it was a good idea to make a leading 0 mean "octal"...

  • (nodebb) in reply to Argle

    Yup, that's rubber duck debugging, and it works great! Explain the problem to someone else in detail, and by the end of the explanation you will often have found the solution yourself. I stopped counting the times I started writing a question on StackOverflow, and found the solution before posting it.

  • Dave (unregistered) in reply to Argle

    It's not even showing them to someone. A lot of problems have obvious answers once you express them clearly. Generally by the time I've thought about what questions I actually want to ask someone, I've already reduced the problem to something I can Google.

  • (nodebb) in reply to Argle

    "Quick follow-up: there seems to be a class of problems. that can only be solved by showing them to someone else." this is why "Four-Eyes" or "Pair" techniques are so valuable. Back 40+ years ago, I would work late, only technical person in the building; the only other human cleaning staff; great guy, but not the sharpest pencil". I would have him come to the computer room so I could explain my problem; it often solved it - even though he did not understand a word [he agreed, because he got a six pack of beer!]

  • (nodebb)

    Make sure to use a coding language which requires "0x" for octal or hex or whatever. Win.

  • a cow (not a robot) (unregistered)

    The same happens when you scanf("%i") a number that starts with 0. A nice "mistery" for the beginner debbuggers ("debbuggers" mening people, not software).

  • a cow (not a robot) (unregistered)

    *meAning

  • (nodebb) in reply to Argle
  • (nodebb) in reply to James F

    What won out was machines with a physical word size that was a multiple of four bits (eight, sixteen, etc.) rather than of three bits (nine, 18, 36, 60, etc.). For multiple-of-three word sizes, octal is better than hex.

    But octal should have been a different prefix, e.g. 0o12 for decimal 10, instead.

  • (nodebb) in reply to Argle

    Quick follow-up: there seems to be a class of problems. that can only be solved by showing them to someone else.

    The sub-serious name for that is "rubber duck problems". The explained-to person often doesn't have to be an actual person. Something like a rubber duck or the cactus on the desk over there will do, although we often, especially in the presence of other people, feel uncomfortable talking to objects like rubber ducks.

  • Yikes (unregistered)

    Somewhere out there, there's someone cursing the person who accidentally entered decimal in a table of octal numbers.

  • ricecake (unregistered) in reply to Hans

    I had a similar issue. I wrote a bash script to organize and archive some log files, and it "mysteriously" stopped working in August.

    This reminds me of a joke: Why do programmers confuse Halloween and Christmas? Because Dec 25 == Oct 31.

  • David Green (unregistered)

    I had to work with someone who was dealing with a similar issue during a system conversion. Their address range matching included leading zeroes for house number ranges, which was fine in his COBOL system, but not for the replacement system we were using.

  • LegacyCodeIsTheGame (unregistered)

    Small nit pick here is that we did have pretty formatting, it was just like something you'd do in a DOS or Terminal window. Based on tabs and spacing. Auto-indenting could be done by emacs. Probably vi (not vim) also. Just don't know because it was the 1990's when I first used vi on an earlier than BSD derived version of Unix.

  • Worf (unregistered) in reply to Steve_The_Cynic

    More correctly, we ended up preferring architectures that had a power of 2 number of bits in them, 4 bit systems 8 bit systems, 16 bit systems, 32 bit systems and 64-bit systems, which pretty much ended up being standardized in the late 70s and early 80s.

    Computers in the 50's, 60's and 70's generally had very odd number of bits indeed - the 3 bit systems were something that emerged rather than happened as any number of bits could be the word size. It's just by the 60s it started being 9 bits, 15 bits and 18 bit word sizes grew common. (Of course, it took all those programmers years to unlearn octal so they were programming 8 bit machines in octal still).

    You still see the odd remnant - if you can never remember how the UNIX permission bits go in chmod, think octal and it suddenly makes a whole lot of sense. And today probably the most widely used computer with octal is likely the Apollo Guidance Computer, which is a 15-bit machine (18 if you include 2 parity and sign bit) that is quite popular at being emulated.

  • (nodebb)

    The closest I've seen was actually on the other end of a string. For an addin application I developed it read links from a database table to load images or other documents. These links were usually entered via copy and paste by staff members. The problem was, sometimes they'd copy an entire line including the trailing carriage return and/or line feed. My application didn't like that as I hadn't made it trim whitespace. It was hard to spot the first time I encountered it though as the EOL characters weren't being displayed when I looked at the string value using the parent application.

  • Mark (unregistered)

    Having previously worked on military C4 systems, it was typical for systems to need to communicate aeronautic transponder codes over the tactical data link. Transponder codes in their most basic form are 4-digit, octal (0-07777). The Mil-Std developers clearly had negligible knowledge of octal vs decimal, so instead treated the octal number as a decimal number, thus we ended up with the absurdity below, instead of just transmitting the octal number in its binary form.

    * 8-9: invalid, 
* 10-17: valid, 
* 18-19: invalid, 
* ...
* 7778-16384: invalid```

And that's probably the mildest WTF in that standard.
  • (nodebb) in reply to Worf

    More correctly, we ended up preferring architectures that had a power of 2 number of bits in them, 4 bit systems 8 bit systems, 16 bit systems, 32 bit systems and 64-bit systems, which pretty much ended up being standardized in the late 70s and early 80s.

    True, but the thing that did in octal in favour of hex was the "divisible by four" verusus "divisible by three" thing. A 28-bit or 20-bit machine would have had the same effect. (Don't laugh at the idea of a 20-bit machine, at least in physical addressing... 8088/86 anyone?)

  • Morton (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to James F

    Yeah, by now pretty much the only things that still use octal are UNIX filesystem permissions and (thanks to Linux still using those) .tar.gz archives.

  • Cloud (unregistered)
    Comment held for moderation.
  • eric bloedow (unregistered)

    reminds me of a time i tried to do a sort...the result came out "1,20,2,20,3,30" etc. the simplest fix was to add zeroes, that is, "01,02,03"

  • Tinkle (unregistered)

    So, the second WTF is that no developer was able to debug it by stepping through and seeing where it fails?

  • PRR (unregistered) in reply to Worf

    "it took all those programmers years to unlearn octal so they were programming 8 bit machines in octal still"

    True that. My father was coding in the 1950s. In retirement he got an INTEL CPU, and translated all the HEX to OCT. (He's still coding, and now in 21st century systems.)

    Octal is better because you don't have to use letters in numbers.

    Being better, naturally you want it quick to enter on slow terminals (I've used 300baud and seen 110baud) so a simple leading zero, K.I.S.S.

  • Alan (unregistered)

    Python acknowledged this pitfall by upgrading from using 0<odigit>... to 0o<odigit>... for octal. I think the blame in this case is either Dennis Ritchie's, or else belongs to someone he could have identified, because BCPL used #X<xdigit>... for hexadecimal and #O<odigit>... or #<odigit>... for octal. C (and possibly B) dropped the requirement for the # character.

  • markm (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Alan

    Almost sounds like somewhere along the line someone got confused between the letter O and the number 0

Leave a comment on “Padded Mailers”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article