Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Jazerus: May 24, 2011

Doom Mathematic posted:

What in the world does the Calibre codebase look like if its own maintainer thinks maintaining Python 2 is easier than migrating the codebase away from it

from what i've heard, you really don't want to know

i think it was a horror in this thread many years ago

# ? Nov 16, 2018 22:40

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 14:40

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Calibre's lead dev also doesn't give a poo poo about blatant security problems, so continuing to use a to-be-dead language shouldn't surprise anybody.

# ? Nov 16, 2018 22:41

Master_Odin: Apr 15, 2010; My spear never misses its mark...

ladies

Suspicious Dish posted:

i guarantee you there will be a community maintained python 2

Well, theoretically Ubuntu and Debian have it in their LTS release till 2023.

I can't wait for python 2 to be finally buried and done with. At least it's mostly looking like we won't have a perl 6 on our hands.

# ? Nov 17, 2018 05:04

Xarn: Jun 26, 2015

McGlockenshire posted:

Calibre's lead dev also doesn't give a poo poo about blatant security problems, so continuing to use a to-be-dead language shouldn't surprise anybody.

Dat attitude

# ? Nov 17, 2018 19:53

ToxicFrog: Apr 26, 2008

Doom Mathematic posted:

What in the world does the Calibre codebase look like if its own maintainer thinks maintaining Python 2 is easier than migrating the codebase away from it

Calibre is great as an ebook/e-reader management tool but as a piece of software it's pretty gross.

# ? Nov 20, 2018 18:25

Remulak: Jun 8, 2001; I can't count to four.; Yams Fan

ToxicFrog posted:

Calibre is great as an ebook/e-reader management tool but as a piece of software it's pretty gross.

All software is pretty gross.

# ? Nov 20, 2018 18:45

Paperboy: Nov 20, 2018

Remulak posted:

All software is pretty gross.

Certain programs like emacs and automake stand out as more gross than average. See: emacs yanking program state out of raw (virtual) memory wholesale, saving it to a temp file, then restoring it upon the program's next start.

# ? Nov 20, 2018 18:56

Zopotantor: Feb 24, 2013; ...und ist er drin dann lassen wir ihn niemals wieder raus...

Paperboy posted:

Certain programs like emacs and automake stand out as more gross than average. See: emacs yanking program state out of raw (virtual) memory wholesale, saving it to a temp file, then restoring it upon the program's next start.

That�s what Smalltalk and many Lisps did, nothing weird about loading a virtual image.
What Emacs does goes beyond that, though�it creates a new executable that contains the dumped image, so it doesn�t need to find and load the image at runtime.

# ? Nov 20, 2018 19:09

ulmont: Sep 15, 2010; IF I EVER MISS VOTING IN AN ELECTION (EVEN AMERICAN IDOL) ,OR HAVE UNPAID PARKING TICKETS, PLEASE TAKE AWAY MY FRANCHISE

Zopotantor posted:

That�s what Smalltalk and many Lisps did, nothing weird about loading a virtual image.
What Emacs does goes beyond that, though�it creates a new executable that contains the dumped image, so it doesn�t need to find and load the image at runtime.

It remains important for performance, cutting startup time from 5 seconds to less than .1 second as of March: https://dancol.org/pdumperpres.pdf

The newer plan is more or less the dumped image version.

All of Emacs is more or less a horror due to 36 years of backwards compatibility, though: https://www.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102

# ? Nov 20, 2018 19:33

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Somebody on this forums joked they'll make a Python 2.9 because GvR said there'd never be a Python 2.8 and I'm just waiting for it to happen.

My problem in going to Python3 is the asshats insisting we target the earliest interpreter of the platforms we support. That is Python 3.3. So we will go from a just-deprecated version to one deprecated two years before.

# ? Nov 20, 2018 22:01

Linear Zoetrope: Nov 28, 2011; A hero must cook

Python 2.9 except the entire changelog is an amendment to the spec that makes it say, in its entirety, "Python 2.9 is, by definition, the latest revision of Python 3 at any given time".

# ? Nov 20, 2018 23:15

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Rocko Bonaparte posted:

Somebody on this forums joked they'll make a Python 2.9 because GvR said there'd never be a Python 2.8 and I'm just waiting for it to happen.

My problem in going to Python3 is the asshats insisting we target the earliest interpreter of the platforms we support. That is Python 3.3. So we will go from a just-deprecated version to one deprecated two years before.

someone already started, and the PSF demanded they change the name. they chose "Tauthon", which is just under "Diaspora" in "really terrible names for things" https://github.com/naftaliharris/tauthon

# ? Nov 21, 2018 02:02

Absurd Alhazred: Mar 27, 2010; by Athanatos

Suspicious Dish posted:

someone already started, and the PSF demanded they change the name. they chose "Tauthon", which is just under "Diaspora" in "really terrible names for things" https://github.com/naftaliharris/tauthon

Why don't they just call it Fighton?

# ? Nov 21, 2018 02:54

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Suspicious Dish posted:

someone already started, and the PSF demanded they change the name. they chose "Tauthon", which is just under "Diaspora" in "really terrible names for things" https://github.com/naftaliharris/tauthon

Oh god, is this a tau-better-than-pi thing?

# ? Nov 21, 2018 04:03

ulmont: Sep 15, 2010; IF I EVER MISS VOTING IN AN ELECTION (EVEN AMERICAN IDOL) ,OR HAVE UNPAID PARKING TICKETS, PLEASE TAKE AWAY MY FRANCHISE

rjmccall posted:

Oh god, is this a tau-better-than-pi thing?

I assume Rhothon and Sigmathon were voted down.

# ? Nov 21, 2018 04:55

Absurd Alhazred: Mar 27, 2010; by Athanatos

ulmont posted:

I assume Rhothon and Sigmathon were voted down.

How about Phởton?

# ? Nov 21, 2018 04:56

ulmont: Sep 15, 2010; IF I EVER MISS VOTING IN AN ELECTION (EVEN AMERICAN IDOL) ,OR HAVE UNPAID PARKING TICKETS, PLEASE TAKE AWAY MY FRANCHISE

Absurd Alhazred posted:

How about Phởton?

That's just silly. Also, Rho, Sigma, and Tau are the next letters following Pi.

# ? Nov 21, 2018 05:07

Absurd Alhazred: Mar 27, 2010; by Athanatos

I still think FightOn is the better choice, but that's too self-aware for them to chose (also probably not as funny as it sounds in my head).

# ? Nov 21, 2018 05:09

Tarezax: Sep 12, 2009; MORT cancels dance: interrupted by MORT

Absurd Alhazred posted:

I still think FightOn is the better choice, but that's too self-aware for them to chose (also probably not as funny as it sounds in my head).

I'm thinking going for a mythological reference with the near homophone of that, Phaeton.

Phaeton was the son of Apollo, and when he met his dad he went and tried to do Apollo's job of pulling the sun across the sky, but hosed it up royally.

Apollo was the patron god of the oracle at Delphi, where the serpent Python was said to dwell.

It's perfect.

# ? Nov 21, 2018 11:19

Absurd Alhazred: Mar 27, 2010; by Athanatos

Tarezax posted:

I'm thinking going for a mythological reference with the near homophone of that, Phaeton.

Phaeton was the son of Apollo, and when he met his dad he went and tried to do Apollo's job of pulling the sun across the sky, but hosed it up royally.

Apollo was the patron god of the oracle at Delphi, where the serpent Python was said to dwell.

It's perfect.

Woah.

# ? Nov 21, 2018 14:53

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

To think this is the same community that gave us the Pantyshot naming fiasco.

# ? Nov 21, 2018 16:27

Falcorum: Oct 21, 2010

Do people count as coding horrors when they refuse to fix/improve a 2s stall in an "open-world" game whenever zoning to a new area?

The stall was because gameplay was doing half a metric shitton of string comparisons instead of enum comparisons. For static data. :dogbutton:

# ? Nov 21, 2018 21:44

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

Doing any amount of string comparisons in a game loop is a coding horror, unless you're making a typing/word game or something like that.

# ? Nov 21, 2018 22:02

Falcorum: Oct 21, 2010

Joda posted:

Doing any amount of string comparisons in a game loop is a coding horror, unless you're making a typing/word game or something like that.

Oh definitely, most of our systems are relatively sane but anything that deals with web requests just ends up being batshit insane because people keep thinking string parsing and later comparing them at runtime is less work than enums for some reason. There's also less bad but still ridiculous things like allocating a string to do a comparison because people never heard of strcmp (when a string comparison is actually needed, which is nearly never).

This was just the most recent (and most terrible so far) issue I've come accross due to strings. :v:

# ? Nov 21, 2018 22:32

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Falcorum posted:

Do people count as coding horrors when they refuse to fix/improve a 2s stall in an "open-world" game whenever zoning to a new area?

The stall was because gameplay was doing half a metric shitton of string comparisons instead of enum comparisons. For static data.

Same co-worker you mentioned before? Or has the infection spread?

# ? Nov 22, 2018 06:42

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

Have they given any justification for refusing to fix this?

# ? Nov 22, 2018 07:38

Falcorum: Oct 21, 2010

Different co-worker unfortunately.

ynohtna posted:

Have they given any justification for refusing to fix this?

He didn't consider it an issue. He got overruled in the end and it's fixed now but still :wtc:

# ? Nov 22, 2018 20:42

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Some people do not know they're types good.

# ? Nov 23, 2018 06:33

nielsm: Jun 1, 2009

You are developing a Windows application for syncing user photos between a PC and your cloud service. Where would you store a local cache of files?

A) In the user profile folder, Local AppData or similar
B) In the shared user profile, C:\ProgramData or similar
C) A folder under C:\Windows\System32

If your choice was C, then congratulations, you made the same choice as Apple did for iCloud. What the gently caress, Apple? :psypop:

# ? Nov 23, 2018 11:37

Volte: Oct 4, 2004; woosh woosh

nielsm posted:

You are developing a Windows application for syncing user photos between a PC and your cloud service. Where would you store a local cache of files?

A) In the user profile folder, Local AppData or similar
B) In the shared user profile, C:\ProgramData or similar
C) A folder under C:\Windows\System32

If your choice was C, then congratulations, you made the same choice as Apple did for iCloud. What the gently caress, Apple?

Apple intentionally makes their Windows stuff extremely lovely. They probably were confronted with this very decision and made sure they chose the worst option.

# ? Nov 23, 2018 15:47

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

Speaking of knowing types and C (although the language rather than the drive / choice)... recently, I found a series of unfortunate events.

Now, C++ supports C-style strings, and they are frequently used. As a reminder, C-strings are just an array of characters and must be null terminated to tell other code where the end is, so you have to be careful with them.

Someone had been using C-strings and copying with strcpy; for those unfamiliar, strcpy will just copy a C-string from a source to a destination blindly without any bounds checking or null terminator checks. So, if you do this:

C++ code:

#define LARGE 100
#define SMALL 20
char src[LARGE];
for(int i=0; i<LARGE - 1; i++)//this is just to init the array for this example
  src[i]='f';
src[LARGE - 1] = 0;
char dest[SMALL];
strcpy(dest, src);

It will happily copy a 100-element array over a 20-element array, overwriting anything between the address for the 20th element in the destination and another 80 bytes further. Besides being destructive, one could exploit an overflow like this to inject malicious code, so it tends to get changed to something else.

Later, someone else changed these to strncpy to 'fix' the fact that the original version had used strcpy. Now, strncpy is not much safer than strcpy, but it does have a bounds that you set to limit the number of characters copied. One typical flaw you'll see with that is someone using sizeof(src).

Interestingly, sizeof is typically a compile-time operation, so it's not a performance hit to use it instead of defines (which is why I'll change the code in the following snippets). It will give you the size of the object in bytes. This is perfectly fine for char (signed or unsigned) since that's always 1 byte length, but needs to be used with care on other types. Using the size of the source C-string for the bounds of the destination C-string is bad for obvious reasons... but that's not what happened here.

The 'fix' was to make the bounds the value of strlen(dest), which was just declared prior to using the strncpy without initialization:

C++ code:

#define LARGE 100
#define SMALL 20
char src[LARGE];
for(int i=0; i<sizeof(src) - 1; i++)//this is just to init the array for this example
  src[i]='f';
src[sizeof(src) - 1] = 0;
char dest[SMALL];
strncpy(dest, src, strlen(dest));

Two problems:
1) strlen uses the null terminator to determine its length.
2) the recently-declared destination had not been initialized as empty, so any stray null terminator in the destination C-string would make strlen shorter than the actual size of the destination C-string. It might be possible to be longer, but I've not been able to get that situation to occur even with tiny C-strings. Maybe compilers these days are just smart enough to at least stick a null terminator somewhere in the C-string at declaration.

A third person had then come and 'fixed' that 'fix' by changing the bounds for strncpy to the sizeof(dest):

C++ code:

#define LARGE 100
#define SMALL 20
char src[LARGE];
for(int i=0; i<sizeof(src) - 1; i++)//this is just to init the array for this example
  src[i]='f';
src[sizeof(src) - 1] = 0;
char dest[SMALL];
strncpy(dest, src, sizeof(dest));

This will prevent overrunning memory past the bounds of the destination array, but we still have a problem: element 20 is still copied over to the destination.

If the character at element 20 is not a null terminator, then any operation that relies on a null terminator will go off into wherever it runs into a 0 in memory. A typical solution to this issue is to just do this:

C++ code:

#define LARGE 100
#define SMALL 20
char src[LARGE];
for(int i=0; i<sizeof(src) - 1; i++)//this is just to init the array for this example
  src[i]='f';
src[sizeof(src) - 1] = 0;
char dest[SMALL];
strncpy(dest, src, sizeof(dest));
dest[sizeof(dest) - 1] = 0;

This will work in the sketchy world that is C / C++, so it's a possible solution to the problem introduced by the chain of events above. It's still not safe even though it seems to be, because someone could potentially do things like this later on:

C++ code:

#define LARGE 100
#define SMALL 0
char src[LARGE];
for(int i=0; i<sizeof(src) - 1; i++)//this is just to init the array for this example
  src[i]='f';
src[sizeof(src) - 1] = 0;
char dest[SMALL];
printf(dest);
strncpy(dest, src, sizeof(dest));
dest[sizeof(dest) - 1] = 0;

Setting the array size to 0 is completely valid code. Doing an operation on index -1 is also valid code, and so is printing the C-string before it's initialized.

The best practice is to always initialize a variable before you use it; so I prefer this solution:

C++ code:

#define LARGE 100
#define SMALL 20
char src[LARGE];
for(int i=0; i<sizeof(src) - 1; i++) //this is just to init the array for this example
  src[i]='f';
src[sizeof(src) - 1] = 0;
char dest[SMALL] = "";
strncpy(dest, src, sizeof(dest) - 1);

This solves a few problems:
1) You will never use the destination C-string without initializing it.
2) The destination C-string will initialize filled with null terminators.
3) sizeof(dest) - 1 is compile-time and will never overwrite the last element (initialized to a null terminator previously) with anything.
4) Someone changing SMALL to 0 will trigger modern compilers that the array isn't big enough for the initialization and flag it as an error.

I won't say this is the best way of dealing with this sort of legacy crap, but I think it's an improvement over what was there.

e: There is one consideration I haven't mentioned - part of strncpy's shtick is to set bytes to 0 that it didn't fill (ex: copying a 20-element array to a 100-element array will fill zeroize the last 80 characters). This makes it slower than strcpy and above a certain threshold (a few thousand characters) slower even than snprintf. snprintf has nearly constant performance regardless of the size of the C-string, and will null terminate. It does have the same danger of strncpy on bounds, so you do need to make sure that's right.

Evil_Greven fucked around with this message at 16:13 on Nov 23, 2018

# ? Nov 23, 2018 15:51

Rubellavator: Aug 16, 2007

nielsm posted:

You are developing a Windows application for syncing user photos between a PC and your cloud service. Where would you store a local cache of files?

A) In the user profile folder, Local AppData or similar
B) In the shared user profile, C:\ProgramData or similar
C) A folder under C:\Windows\System32

If your choice was C, then congratulations, you made the same choice as Apple did for iCloud. What the gently caress, Apple?

Apple has to assert its dominance in the host system

# ? Nov 23, 2018 15:57

Volguus: Mar 3, 2009

Volte posted:

Apple intentionally makes their Windows stuff extremely lovely. They probably were confronted with this very decision and made sure they chose the worst option.

Nah, I'm sure that even on their MacOS they probably put those pictures in /sbin or /usr/sbin . Which is why, when they googled "system executables in windows" they stumbled over "c:\windows\system32".

# ? Nov 23, 2018 16:17

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

Evil_Greven posted:

Now, C++ supports C-style strings, and they are frequently used.

...

If your intent really is to truncate strings larger than the destination buffer, see if strlcpy() is available to you.

In general though, I would recommend not using c-strings and fixed size buffers in c++ unless there is some hard constraint preventing you from using std::string. Without constant vigilance, people will repeat the mistakes you've described. Better to just just replace the legacy code with std::string imo.

# ? Nov 23, 2018 16:38

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

Illusive gently caress Man posted:

If your intent really is to truncate strings larger than the destination buffer, see if strlcpy() is available to you.

In general though, I would recommend not using c-strings and fixed size buffers in c++ unless there is some hard constraint preventing you from using std::string. Without constant vigilance, people will repeat the mistakes you've described. Better to just just replace the legacy code with std::string imo.

It, unfortunately, is not available.

I'd like to replace the whole drat thing like you suggest, but we just do not have the time to do a complete overhaul. I'm fixing things incrementally as we have changes to make, killing warnings, etc. It's a slow process.

Evil_Greven fucked around with this message at 16:44 on Nov 23, 2018

# ? Nov 23, 2018 16:42

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

Falcorum posted:

He didn't consider it an issue. He got overruled in the end and it's fixed now but still

drat. That boy needs to learn some righteous impatience.

Reminds me when I was working on mid-90s games and a co-worker swore blind that their menu screens implementation - nothing fancy, just your bog standard simple full-screen non-animated 2D start, load, save, & options - was physically incapable of running faster than 4 FPS. Despite our sloppy vintage software rendering 3D engine (plus full game & audio systems) running at ~30 FPS on the same dev hardware, having the mouse cursor lag-teleport when the game was paused and only his UI code ran was simply the best that could be done. :psypop:

# ? Nov 23, 2018 17:22

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Evil_Greven posted:

Speaking of knowing types and C (although the language rather than the drive / choice)... recently, I found a series of unfortunate events.

I mean, yeah, but this is just classic "stumbling in the dark with C." As opposed to, say, writing your own "optimized" strcpy that not only does not have any awareness of boundaries but has an off-by-one bug.

# ? Nov 24, 2018 00:05

Evil_Greven: Feb 20, 2007; Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

Rocko Bonaparte posted:

I mean, yeah, but this is just classic "stumbling in the dark with C." As opposed to, say, writing your own "optimized" strcpy that not only does not have any awareness of boundaries but has an off-by-one bug.

The real horror is that every one of the people who did these things has years of experience more than me, allegedly to some extent with C/C++.

I kind of wonder if folks just don't bother to make sure poo poo does what they think it will. It's not exactly hard to write a test program to verify assumptions on something like this, but c'est la vie .

# ? Nov 24, 2018 00:26

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

The last time I was prodding around in C++ was around 2010, but back then it really did look like a pain to unit test in C/C++. There was not much out there that would run the tests in another process to keep the suite running if something segfaulted, which I consider to be pretty important. But we both know that was not what hampers your colleagues . . .

# ? Nov 25, 2018 02:15

Adbot: ADBOT LOVES YOU

# ? Jun 7, 2024 14:40

MrMoo: Sep 14, 2000

libCheck is great for that in C, but you need to work with something else for C++ unless you catch SEH on Windows. Spooning with Boost.Test on a new project and will see how that copes.

# ? Nov 26, 2018 05:08

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »