Let's talk about about C++, as it deserves it from time to time.
Especially because I've lost a couple of days on a not-enough-advertised-feature:
std::ifstream in;
in.open("somefile",std::ifstream::out);
(
https://www.destroyallsoftware.com/talks/wat)
Opening an input file stream for output is not at all convoluted.
It's both a crystal clear code and a brilliant idea!
Good enough to transcribe it in the standard library:
http://www.cplusplus.com/reference/fstream/ifstream/open/
What difference does it make with fstream? Or should I rather open an ofstream for input? It leaves plenty of room for speculation. if someone knows, he shall write a blog post immediately!
But if the standard offers some weird path, by virtue of Murphy's law, be sure that someone will follow it, whether accidentally or not.
Murphy's law has more to offer: Microsoft implementation changed somewhere between .NET 2003 and .NET 2010, so that opening an input file stream for output on a write-protected file does now fail, what it didn't previously...
Of course, the file has to be read only at deployment site, not in developer's configuration where we have debuggers, otherwise things would be much too trivial.
Recompiling a legacy application while not exerting enough code review is a dangerous thing, so let's not blame C++ for our own mistakes. Except that C++ did not especially help here.
My colleagues said: "tu-mourras-moins-bete" (auf deutsch). Not so sure: I feel like this kind of information is not going to reduce the entropy in my brain.
I'm not going to change C++. I can't. But I'm itching to simplify our own Squeak Stream hierarchy with such reduction of entropy in mind. Don't push me!
Previous post was about alignment problems in Smallapack matrix inversion. Let us look at another one that crippled the jpeg plugin for 64 bits windows flavour of opensmalltalk Virtual Machine (issue 119).
The problem originate at win64 requirement for jmp_buf type used in setjmp/longjmp: it must be 16-bytes aligned. I couldn't find a reference to this requirement, but there is a definition in some header that ensure such alignment. Appropriate cygwin grep in /usr/x86_64-w64-mingw32/sys-root/mingw/include will reveal:
setjmp.h: typedef _JBTYPE jmp_buf[_JBLEN];
setjmp.h: typedef SETJMP_FLOAT128 _JBTYPE;
setjmp.h: typedef _CRT_ALIGN(16) struct _SETJMP_FLOAT128 {
With such definitions, the C compiler will manage to properly align the data, so we don't have to worry... Or do we?
We use setjmp/longjmp for the purpose of error handling (and properly quiting the primitive). But we had the brilliant idea to put such jmp_buf member in a structure (see JPEGReadWriter2Plugin/Error.c).
The layout of the structure cannot vary for each instance, so if we want one member to be aligned on 16bytes boundary, the sole solution is to align the whole structure itself to 16bytes boundary, and fill enough gaps between members. Alas, both gcc and clang fail to do so. I don't know if I should report a bug for that.
Imposing that requirement to our own structure, in a portable and future-proof way is less than obvious. So the workaround was rather to use a pointer on a jmp_buf - see pull request #120.
This kind of bug is pretty tricky, but if you have to implement some VM parts in C, what do you expect?
Opening an input file stream for output is not at all convoluted.