Hi guys,

I just wrote a small tool that relies on argv[0] containing the exe's path / name. But if the program is inside a folder with a white-space somewhere, this fails.
Asume the program xyz.exe is inside "work:test me/" and it is started by typing

"work:test me/xyz.exe" param1 param2
then
argv[0] = work:test
argv[1] = param1
argv[2] = param2

So argv[0] only contains the characters until the first white-space :(

I'm still running MorphOS 3.3, so maybe this is fixed already.
But if it is not... a real show-stopper-bug!
Nobody else stumbled into that yet?

Cheers,
Daniel

[ Editiert durch Daytona675x 27.07.2014 - 06:19 ]

The same problem happened to me with the old-ish SDK I had installed on my Mac Mini, but after grabbing updating to the latest SDK from the website, it went away. So chances are that if you do the same, that'll fix the problem for you too.

@bigfoot
So you're saying that this is some bug in my exe due to some buggy statically linked startup-code?
Okay, to verify that I have to update my cross-compiler setup first (its SDK is not horribly outdated but not the latest).
In any case: I updated my MorphOS installation (and the SDK installation on that machine) to 3.6, issue persists.

UPDATE:
linking against latest SDKs libs, exe now significantly smaller but issue still there

[ Editiert durch Daytona675x 27.07.2014 - 09:16 ]

I'm saying that I could reproduce the problem with whatever (old) version of the SDK I had installed on my Mac Mini this morning. I updated the SDK on the Mac Mini to the latest version and I could no longer reproduce the problem. And yes, the responsible code is in the startup file that gets statically linked.

I just tried reinstalling the latest SDK again and I can still not reproduce the problem.

I can reproduce it when compiling and linking an ixemul exe (this is the default). Not when compiling and linking a libnix one (using -noixemul, which is usually what one wants to produce MorphOS binaries).
Which one do you use?

... you could try making a small test program. If you're still reproducing the problem with it, then post both the source code and the binary produced somewhere online and I'll see whether I can reproduce it here.

Henes,

Hmm, indeed. I was sure I remembered -noixemul the first time I tried, though... Maybe I had messed up my SDK in unimaginable ways :P

@Henes:
thanks a lot, -noixemul did the trick.
But WTF...

The "-noixemul" compiler and linker argument controls which includes, startup code and libc is going to be used.
So... different behaviour and bugs are to be expected.

Quote:

Indeed...
Turns out that some socket code isn't working now, great.
Okay, since I have full control about how this program is used I will workaround the argv[0] issue by simply calling the program with another additional parameter, containing what argv[0] should be if things were sane, and use ixemul.
Easier to work around that issue than to start looking for that socket-problem -noixemul introduced.

Thanks anyway!

I guess you are just about to discover what ixemul and libnix are... :)
There might be some information about it somewhere on morphzone.

Basically, MorphOS is not an Unix.
If you build your code for ixemul, the posix calls try to be somehow emulated but you can't really really use other MorphOs shared libaries or you will run into all kind of weird troubles.
If you build for libnix (like nearly everything out there, including MorphOS itself) then you can still use "C" (not POSIX !) library but you must forget custom Unix API and way of doing (f.e. forget using select() on a socket). Welcome to MorphOS :)

@Henes

I just took a quick look at the ixemul sources (just noticed they're available on the MorphOS downloads page).

The argv[0] evil seems to happen here:
file: _cli_parse.c
lines: 424-429

Code:

Too funny that the guy who's responsable for that put a comment there to point out how smart he is (or how dumb others are)

Okay, now, shall I report that snippet through MorphOS' integrated bug reporter? Or how do I make sure this gets fixed?

Cheers,
Daniel

[ Editiert durch Daytona675x 03.08.2014 - 12:01 ]

Yep, we already identified that code as the likely culprit, however we haven't had time to test and fix it yet.

It's already in the bug tracker (via a previous bug report of yours I think, thanks!), so no need to submit it again.