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 »

b0lt: Apr 29, 2005

pseudorandom name posted:

Sadly, this will still require you to link against libstdc++, which is just a time bomb waiting for the standard committee or gcc to break unrelated C++ libraries in your application.

the last time libstdc++ broke abi compatibility was over a decade ago

# ? Feb 16, 2015 23:36

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 14:39

Bhodi: Dec 9, 2007; Oh, it's just a cat.; Pillbug

Thermopyle posted:

I mean, I know nothing about this poo poo, but this sounds like gobbedly-gook from CSI. Multiple branches? Oh no we're hosed!

It's a complete encrypted virtual filesystem using registry entries like you would use sectors on a hard drive. Each sector is broken up into small bits and squirreled away in various backwater places on the registry. Inside that filesystem lives a program divided up into different encrypted modules, each with their own separate decryption key to more easily obscure their use. They're decrypted when needed and the controller is side loaded by code from a hacked MBR that injects code into the kernel at boot time, or maybe from a hidden partition on your hard drive created by a program more universal than nvidia drivers that literally flashes hard drive's firmware.

It's like made up poo poo you'd see in CSI, but actually real

# ? Feb 16, 2015 23:44

omeg: Sep 3, 2012

There was a guy that ran Linux on a HDD itself. There were talks about reprogramming flash drive controllers to do malicious stuff with the filesystem. I wonder when someone cracks the modern x86 CPU microcode and does some funky poo poo with that. Would probably require stealing documentation from Intel, but who knows.

E: http://spritesmods.com/?art=hddhack

omeg fucked around with this message at 23:55 on Feb 16, 2015

# ? Feb 16, 2015 23:52

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

My problem is that simply swapping gcc with g++ slows down compiles by an order of three or so, which is just ridiculous.

By the way, has the C++ standards committee gotten written of trigraphs yet?

EDIT: oh hey, they're gone in C++17!! yay! What was IBM's opposition?

EDIT 2: lmao "There are real customers who use EBCDIC. We cannot reveal their names due to confidentiality agreements. "

Suspicious Dish fucked around with this message at 00:04 on Feb 17, 2015

# ? Feb 17, 2015 00:02

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

Suspicious Dish posted:

EDIT 2: lmao "There are real customers who use EBCDIC. We cannot reveal their names due to confidentiality agreements. "

That was the argument they used in C++14 too, but apparently then the WG wasn't sufficiently sick of trigraphs yet

# ? Feb 17, 2015 00:11

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

pseudorandom name posted:

Sadly, this will still require you to link against libstdc++, which is just a time bomb waiting for the standard committee or gcc to break unrelated C++ libraries in your application.

Wait, why? What am I forgetting that still introduces a dependency on the standard library?

# ? Feb 17, 2015 01:12

KernelSlanders: May 27, 2013; Rogue operating systems on occasion spread lies and rumors about me.

Maluco Marinero posted:

When I was getting started on python, "%s thing" % (thing) always always caught me out.

That has nothing to do with type safety, though. I can do the same thing in scala.

code:

object pyString {
  implicit class pyStringFormatter(fmt: String) {
    def %(s: Any*) = fmt.format(s:_*)
  }
}

import pyString._

"hi %s are you %d" % ("foo", 3)

# ? Feb 17, 2015 03:36

pseudorandom name: May 6, 2007

rjmccall posted:

Wait, why? What am I forgetting that still introduces a dependency on the standard library?

libsupc++ isn't available separately from libstdc++, so the things that haven't changed ever (new, delete, etc.) are stuck with iostreams and the containers and whatnot

# ? Feb 17, 2015 03:45

sarehu: Apr 20, 2007; (call/cc call/cc)

qntm posted:

Are you seriously telling me that a character literal doesn't have type char?

Not only that, but guess what this prints in many compilers:

code:

  int x = 'AM';
  printf("%x\n", x);

# ? Feb 17, 2015 03:50

b0lt: Apr 29, 2005

sarehu posted:

Not only that, but guess what this prints in many compilers:
code:
  int x = 'AM';
  printf("%x\n", x);

A warning about multicharacter literals?

# ? Feb 17, 2015 04:17

sarehu: Apr 20, 2007; (call/cc call/cc)

I mean in the generated programs

# ? Feb 17, 2015 04:20

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

414d

# ? Feb 17, 2015 04:59

Deus Rex: Mar 5, 2005

b0lt posted:

A warning about multicharacter literals?

Multicharacter constants in C++ are legal with implementation-defined values and, unlike single character constants in C++, are of type int.

# ? Feb 17, 2015 05:21

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

pseudorandom name posted:

libsupc++ isn't available separately from libstdc++, so the things that haven't changed ever (new, delete, etc.) are stuck with iostreams and the containers and whatnot

Okay, sure, but unless you need to transfer responsibility for memory across a dynamic library boundary, you can define those in your library to use malloc/free (with hidden visibility to avoid affecting anybody else).

I mean, C also requires a basic runtime. Even in freestanding mode, both gcc and clang can and will emit calls to memcpy, memset, etc.

# ? Feb 17, 2015 05:51

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

KernelSlanders posted:

That has nothing to do with type safety, though. I can do the same thing in scala.
code:
object pyString {
  implicit class pyStringFormatter(fmt: String) {
    def %(s: Any*) = fmt.format(s:_*)
  }
}

import pyString._

"hi %s are you %d" % ("foo", 3)

You missed my point. What I posted would render only the first character of the variable because the duck typing can accept any old iterable with printable elements, thus treating it as a list of single characters. The correct way to write what I wrote in python to get expected behaviour would be "%s thing" % (thing,) -- because then it would be interpreted as a single element tuple.

Your Scala approach isn't vulnerable to that. I only brought it up because it was something that tripped me up all the time in my early days of learning Python (which was my first proper effort at building a thing). The duck typing aspect is what tends to make all this behaviour loose as hell, and to be honest feels more confusing than giving solid interfaces for people to conform with.

As an example, I really love that if I know there's a kind of function I need in Haskell, I can basically take what I know I want the type signature to look like, plug it in to Hoogle, and then likely find the api or library I'm looking for. Duck typing won't get you that very cheaply.

# ? Feb 17, 2015 11:09

Soricidus: Oct 21, 2010; freedom-hating statist shill

Maluco Marinero posted:

When I was getting started on python, "%s thing" % (thing) always always caught me out.

Maluco Marinero posted:

You missed my point. What I posted would render only the first character of the variable because the duck typing can accept any old iterable with printable elements, thus treating it as a list of single characters. The correct way to write what I wrote in python to get expected behaviour would be "%s thing" % (thing,) -- because then it would be interpreted as a single element tuple.

Nope.

code:

>>> thing = 'wrong'
>>> "%s thing" % (thing)
'wrong thing'

# ? Feb 17, 2015 11:17

bobthecheese: Jun 7, 2006; Although I've never met Martha Stewart, I'll probably never birth her child.

Not sure if I've ever posted this one before... but some of the software I'm working on has a novel approach to 'templates'...

php:

<?
$filename = "/path/to/global/styles.css";
$handle = fopen ($filename, "r");
$cssStyles = fread ($handle, filesize ($filename));
fclose ($handle);
$html.="<html>
<head>
<style type='text/css'>
$cssStyles
</style>
</head>
<body>
";
$html.="<br><div class=\"pageHeaderBlue\">Page title</div><br>";
echo $html;
?>

On every page.

Which is 873 pages.

# ? Feb 17, 2015 11:45

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

I like how the CSS is read into the file every time. I would suggest that maybe they were trying to minimize the number of network requests, but I think it's more likely they've never heard of the link element.

# ? Feb 17, 2015 16:06

substitute: Aug 30, 2003; you for my mum

:goatse:

Only registered members can see post attachments!

# ? Feb 17, 2015 17:17

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

b0lt posted:

the last time libstdc++ broke abi compatibility was over a decade ago

They're finally breaking forward-compatiblity with 5.0 to bring std::string in line with C++11, but that still won't break any existing binaries unless you're exposing std::string over a shared library interface and recompile that shared library with the incorrect compiler settings.

# ? Feb 17, 2015 17:50

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Soricidus posted:

Nope.

code:

>>> thing = 'wrong'
>>> "%s thing" % (thing)
'wrong thing'

That's embarrassing. Y'know what, it was probably using field arguments in Django, where that can be an issue. Oh well, should prob'ly test my throwaway code from now on.

# ? Feb 17, 2015 18:15

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Maluco Marinero posted:

That's embarrassing. Y'know what, it was probably using field arguments in Django, where that can be an issue. Oh well, should prob'ly test my throwaway code from now on.

I would have sworn you were right.

Maybe in an older Python version?

# ? Feb 17, 2015 19:26

No Safe Word: Feb 26, 2005

No, it was never that way, but

code:

(thing, )

was (and still is) the only way to make a single-element tuple (though the parentheses are optional in most cases)

# ? Feb 17, 2015 19:29

Karate Bastard: Jul 31, 2007; Soiled Meat

Strings being iterable for characters is perhaps my most frequent stupid slipup in python. Especially since strings are extremely convenient to name confusingly to annoy yourself with. Example:

ids = open("ids.txt").read()#oops forgot .split()
for identifier in ids: #Nope haha

# ? Feb 17, 2015 19:42

Gul Banana: Nov 28, 2003

Suspicious Dish posted:

EDIT 2: lmao "There are real customers who use EBCDIC. We cannot reveal their names due to confidentiality agreements. "

i mean, this is TRUE (i worked at ibm), it's just not a very convincing argument.

# ? Feb 17, 2015 19:50

MrMoo: Sep 14, 2000

bobthecheese posted:

Not sure if I've ever posted this one before... but some of the software I'm working on has a novel approach to 'templates'...
php:
<?
$filename = "/path/to/global/styles.css";
$handle = fopen ($filename, "r");
$cssStyles = fread ($handle, filesize ($filename));
fclose ($handle);
$html.="<html>
<head>
<style type='text/css'>
$cssStyles
</style>
</head>
<body>
";
$html.="<br><div class=\"pageHeaderBlue\">Page title</div><br>";
echo $html;
?>
On every page.

Which is 873 pages.

Tell them to update to readfile first ...

# ? Feb 17, 2015 19:59

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

Gul Banana posted:

i mean, this is TRUE (i worked at ibm), it's just not a very convincing argument.

So there are people still using EDCBIC in tyool 2015, and they want to compile newly written C++17 code without putting it through a minimal translation pass?

# ? Feb 17, 2015 21:31

ExcessBLarg!: Sep 1, 2001

I completely understand that IBM has customers that may well routinely deal with EDCBIC data, but do they seriously need EDCBIC source support? Is this poo poo not cross-compiled?

# ? Feb 17, 2015 21:49

Soricidus: Oct 21, 2010; freedom-hating statist shill

Suspicious Dish posted:

So there are people still using EDCBIC in tyool 2015, and they want to compile newly written C++17 code without putting it through a minimal translation pass?

ExcessBLarg! posted:

I completely understand that IBM has customers that may well routinely deal with EDCBIC data, but do they seriously need EDCBIC source support? Is this poo poo not cross-compiled?

Come now, you've both of you seen enough that you should not find this claim remotely unbelievable.

# ? Feb 17, 2015 23:18

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

I'm sure that there are banks and other customers with EDCBIC support, but I thought they were writing COBOL, not C++17.

# ? Feb 17, 2015 23:29

TheresaJayne: Jul 1, 2011

Suspicious Dish posted:

I'm sure that there are banks and other customers with EDCBIC support, but I thought they were writing COBOL, not C++17.

Well i know most insurance firms run their systems on Mainframes using cobol so i guess most of them are EDCBIC.

# ? Feb 18, 2015 08:12

Gul Banana: Nov 28, 2003

It's actually quite an interesting situation. My knowledge is a few years out of date, but here's how things stood when I quit:

Mainframes, variously branded System/360, System/370, System/390 and now "System z", are used by big companies in certain industries, delivering $trust_me_its_a_lot_of_money in revenue. Occasionally this is because a single really big computer is ideal for the task, but more often backwards compatibility rules the day. You can run a binary built in, i'm not exaggerating, 1965 on one of these things and it will work. That is a supported scenario. To some clients, this capability is worth billions.

Of course most of them don't really care about binaries from the 60s- but they care a great deal about source code that originated in the 70s and 80s and has been continuously updated since. It encodes so much business logic that porting to a new OS is basically insane and will never happen as long as IBM is still in business. IBM is just fine with this and want to encourage it as a continuing business model- so they keep up new development. zSeries has been updated continuously with new hardware, operating systems, applications and so on for >50 years. Thousands of programmers at IBM work on the OSes alone - I was one.

I say 'OSes' because there are several. you *can* run linux on mainframes, and some people do, but the legacy operating systems - zOS, zVM, zTPF - these are the backwards compatible ones, the ones that are part of the business model. So these systems need to be built, as well as middleware and applications - that's tens of thousands of developers minimum before you even get to the third-party ecosystem.

These particular developers are not using COBOL. The thing about COBOL is that it was always a *line of business* language; it was the Visual Basic of mainframes. you don't write a security server or a GUI or a logon mechanism or a database or a kernel in it. You write something that processes reports and applies rules on large data volumes according to regulations; you might write a CICS transaction in COBOL, but CICS itself also has to be written.

So for systems and applications development in the mainframe ecosystem, people use a bunch of different stuff- "high-level" assembly, Java, internal IBM languages that i don't think i can talk about, and of course C. C and C++ aren't the absolute majority but they're in heavy use. IBM has its own compiler teams in various labs, including several separate ones for C. I wrote [url=http://www-01.ibm.com/support/knowledgecenter/SSKS6B_7.0.1/welcomePage/AMSZosWelcomePage.htm]this in C++, happily using features from what was then C++0x.

Where does EBCDIC comes into this? EBCDIC was the native character set of system z. It still is for z/OS and z/TPF (VM is a virtualising hypervisor, so it doesn't matter much there). You can run zLinux if you want ASCII but not many people do. So when you're writing C++ for a mainframe, naturally your source code is *on* the mainframe in a "PDS" (closest equivalent to a "directory"). It's edited there with mainframe-based IDEs and stored in mainframe-based source control. Cross-compilation generally does not make sense - you want to link with languages that don't even exist on the PC, emitting code for an architecture the PC has never had. there are some real fundamental differences in the runtime model, as this stuff predates the PC consensus - there aren't "processes", "files" or "drivers" (although all those things have their equivalents, they don't combine in the same way).

Generally when editing and compiling your code you'll use a special code page which does have { } - but some systems will be in a locale that just doesn't and never will support certain characters. So ultimately IBM's opposition is reasonable; trigraphs were created to allow for systems which predate ANSI, and those systems are still being actively used and developed today.

That doesn't mean they should get their way. This stuff just does not matter to most people and is holding back everyone else. In practice, IBM will continue to support trigraphs in XL C and its other compilers, as a nonstandard extension; they'll face resistance when trying to use them in open source code bases, but they have the manpower to just maintain forks. Someday the mainframe will die, but people have been predicting that to be imminent since the release of the VAX.

# ? Feb 18, 2015 15:56

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Gul Banana posted:

Cross-compilation generally does not make sense - you want to link with languages that don't even exist on the PC, emitting code for an architecture the PC has never had. there are some real fundamental differences in the runtime model, as this stuff predates the PC consensus - there aren't "processes", "files" or "drivers" (although all those things have their equivalents, they don't combine in the same way).

None of that is in any way incompatible with cross-compilation. The things a compiler emits and the things that can actually run on the machine the compiler is running on don't need to resemble each other.

# ? Feb 18, 2015 16:40

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Gul Banana posted:

Where does EBCDIC comes into this? EBCDIC was the native character set of system z. It still is for z/OS and z/TPF (VM is a virtualising hypervisor, so it doesn't matter much there). You can run zLinux if you want ASCII but not many people do. So when you're writing C++ for a mainframe, naturally your source code is *on* the mainframe in a "PDS" (closest equivalent to a "directory"). It's edited there with mainframe-based IDEs and stored in mainframe-based source control. Cross-compilation generally does not make sense - you want to link with languages that don't even exist on the PC, emitting code for an architecture the PC has never had. there are some real fundamental differences in the runtime model, as this stuff predates the PC consensus - there aren't "processes", "files" or "drivers" (although all those things have their equivalents, they don't combine in the same way).

Generally when editing and compiling your code you'll use a special code page which does have { } - but some systems will be in a locale that just doesn't and never will support certain characters

Does this mean that these machines just have no way of storing/reading code that has certain characters?

# ? Feb 18, 2015 17:18

Gul Banana: Nov 28, 2003

Plorkyeran posted:

None of that is in any way incompatible with cross-compilation. The things a compiler emits and the things that can actually run on the machine the compiler is running on don't need to resemble each other.

Why would they go to the effort of porting parsers + the equivalent of 'header files' for PL/X, REXX, HLASM etc to PC when they can just run a compiler on the very fast mainframe?

Actually, an interesting historical note: the norm for a long time WAS that vendors in the mainframe ecosystem shipped software to their customers as the equivalent of .o files, to be linked on the target system- it was a form of package management and forwards-compatibility.

Munkeymon posted:

Does this mean that these machines just have no way of storing/reading code that has certain characters?

Generally they support arbitrary code pages, as does any abstracted software, and can convert between them. You can create an EBCDIC text file on windows too, it will just be a hassle to convert it back and forth. The issue is that the whole point of the ecosystem is backwards compatibility - being able to read/edit/build/run your stuff WITHOUT having to port or transform it is what people are paying for.

The hardware people in particular go to some really extreme measures to support both old and new paradigms. The mainframe 'CPs' (which are basically a MCM of cpus with several cores per die) support a number of different microcode formats including specific acceleration for java bytecode and emulation of x86, running in either big or little endian, all sorts of privilege/ring models, maths in packed decimal or IEEE or weird ancient russian standards.. the sort of crazy stuff you can do when you charge a thousand times as much as Intel.

# ? Feb 18, 2015 20:16

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

Plorkyeran posted:

None of that is in any way incompatible with cross-compilation. The things a compiler emits and the things that can actually run on the machine the compiler is running on don't need to resemble each other.

The real reason is probably that their toolchains are written in mainframe-ese and nobody can be assed to port them. Also, writing a toolchain that only targets the host dramatically simplifies certain kinds of things, because (in C terms) you can just include a header and ask the host compiler for type sizes and field offsets instead of abstracting that stuff properly for cross-compilation. That's only marginally useful for a compiler but much more useful for the assembler, linker, and other object-file tools.

# ? Feb 18, 2015 20:18

ExcessBLarg!: Sep 1, 2001

How do people actually interact with the mainframe? Presumably line printers are gone. Do they use terminal emulators on desktops? Are they reasonably VT-compatible (not sure how EBCDIC actually plays into that)?

So, honestly, I would've imaged that once C language software became popular they would've converted old code using trigraphs to a newer EBCDIC variant that supports C language syntax natively. Surely they must do something like that in order to pull in C code written on different platforms, unless it's a truly closed ecosystem. I get backwards compatibility, but continuing to march forward with trigraphs, which were a stopgap measure to begin with, seems particularly crazy.

# ? Feb 18, 2015 20:21

Gul Banana: Nov 28, 2003

ExcessBLarg! posted:

How do people actually interact with the mainframe? Presumably line printers are gone. Do they use terminal emulators on desktops? Are they reasonably VT-compatible (not sure how EBCDIC actually plays into that)?

You use terminal emulators, but the protocol is 3270 rather than VT100- mainframe terminals are screen- rather than line- oriented, with a bunch more features. Remember, this was the 'big iron' to UNIX's miniaturized cut-down etcs. It looks like this:

Which brings us back to the topic of the thread.

# ? Feb 18, 2015 20:29

ExcessBLarg!: Sep 1, 2001

code:

BITS = BITS && BITS;

# ? Feb 18, 2015 20:40

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 14:39

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

ExcessBLarg! posted:

converted old code

This basically never happens successfully. Maybe the next version is in a different language, but for a lot of this code there isn't and never will be another major version.

# ? Feb 18, 2015 20:41

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 »