Forum > macOS / Mac OS X
Difference in ParamStr(0) between running with Debugger and running without
TRon:
Please forgive my ignorance on the subject but can't this be solved by checking if paramstr(0) is in fact a symlink and then resolve the link ? Is about 2 lines of code.
Martin_fr:
--- Quote from: TRon on November 07, 2024, 04:36:33 pm ---Please forgive my ignorance on the subject but can't this be solved by checking if paramstr(0) is in fact a symlink and then resolve the link ? Is about 2 lines of code.
--- End quote ---
Well, any user can add that to their own application, so yes.
But, IMHO, the function ParamString should return whatever the OS says. Or follow OS convention.
I don't think correcting this in this function is the way to go. And if lldb can call the exe in a way that causes this then user might be able to (if starting from console, or whatever). And then there may even be projects that use ParamString to test for this. So changing ParamString could be seen as introducing a regression.
TRon:
@Martin_Fr:
Yes, I agree with that general note.
However, but I might be understanding the reported issue wrong, this seems to be particular about the difference in behaviour whether or not the application was started using the debugger.
So, when invoking the debugger the invocation function could check for this and revolve the 'proper' name and pass that the debugger ? I do not know what the 'normal' behaviour is for the debugger in use (e.g. whether or not it should actually be the debugger that does this to make sure the behaviour is the same)
I am not sure if doing such a thing could interfere with other expected behaviour.
FWIW: I am aware that (as advertised) code should not rely on paramStr(0) whatsoever for certain platforms.
carl_caulkett:
--- Quote from: Martin_fr on November 07, 2024, 04:33:04 pm ---How would one modify the ParamString? Other than changing the source code of the project that is being debugged, but that doesn't make sense?
--- End quote ---
No! I meant altering the code within this function paramstr(l: longint) : shortstring; within ./fpcsrc/rtl/bsd/system.pp (this is the code revealed by the debugger, which makes sense because macOS is really FreeBSD in disguise ;))
URGENT UPDATE: The previous comment about macOS and FreeBSD was a joke, albeit one based on tenuous links with reality. Please do not spread rumours or any kind of misinformation based thereupon :o
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- { variable where full path and filename and executable is stored } { is setup by the startup of the system unit. }//var// execpathstr : shortstring; function paramstr(l: longint) : shortstring; begin { stricly conforming POSIX applications } { have the executing filename as argv[0] }// if l=0 then// begin// paramstr := execpathstr;// end// else if (l >= 0) and (l < argc) then paramstr:=strpas(argv[l]) else paramstr:=''; end;
There's already commented out code that deals with the special case of argv[0], though it seems that this was an attempt to tweak the behaviour which was abandoned...
Martin_fr:
@TRon:
The debugger does not invoke that function. The debugger tells the OS to start a process, giving the os stuff like: the current dir, the full name of the process, the command line args, env-vars....
The app (running inside or outside the debugger) then queries that (from the OS) and does whatever it needs to do.
On Mac, you can start an exe by "opening" the app bundle (the normal way), or by invoking the exe in the app bundle.
The debugger currently does the latter. On Mac, in this context the debugger involves lldb, and to an extend what the IDE tells lldb to do. => And I don't currently know, if lldb can be told to do it in some other way.
@Carl_caulkett
You can approach the fpc team on that. I am doubtful of this having any chance... But I am not part of the FPC team, so ...
It also means that it would only work when using those methods. Any raw access would still disclose that the debugger caused a difference.
Navigation
[0] Message Index
[#] Next page
[*] Previous page