Not sure if this one has come up yet, but I have been experiencing some strange behavior in that some of my strings seem to disappear when used as parameters for procedure calls.
I'm not in a position to offer a demo program, and unfortunately, this does not seem to happen in every situation, but here is in essence what is happening. Consider:
TYPE STRING63 = STRING(63);
FUNCTION x : STRING63; { returns a nonempty string }
PROCEDURE y(z, t : STRING63); { ... }
VAR a, b : STRING63;
BEGIN a := 'hi'; y(x, a); <..>
Now if I try to use t within y, I should get the string 'hi', but it turns out to be an empty string (even if I WRITE(t) immediately after the opening BEGIN in the procedure). However, if I do this:
a := 'hi'; b := x; y(b, a);
then it works correctly.
There seems to be a problem with using a function returning a string (maybe just one with no parameters?) directly as an argument to a procedure. Storing the result in a variable then using the variable as the parameter solves the problem.
Obviously this creates a simple workaround, but it is still a bug...
----------------------------------------------------------- Frank D. Engel, Jr. fde101@fjrhome.net
____________________________________________________________ Free 20 MB Bannerless Domain Hosting, 1000 MB Data Transfer 10 Personalized POP and Web E-mail Accounts, and more. Get It Now At www.doteasy.com
Frank D. Engel, Jr. wrote:
Not sure if this one has come up yet, but I have been experiencing some strange behavior in that some of my strings seem to disappear when used as parameters for procedure calls.
I'm not in a position to offer a demo program, and unfortunately, this does not seem to happen in every situation, but here is in essence what is happening. Consider:
TYPE STRING63 = STRING(63);
FUNCTION x : STRING63; { returns a nonempty string }
PROCEDURE y(z, t : STRING63); { ... }
VAR a, b : STRING63;
BEGIN a := 'hi'; y(x, a); <..>
Now if I try to use t within y, I should get the string 'hi', but it turns out to be an empty string (even if I WRITE(t) immediately after the opening BEGIN in the procedure). However, if I do this:
a := 'hi'; b := x; y(b, a);then it works correctly.
There seems to be a problem with using a function returning a string (maybe just one with no parameters?) directly as an argument to a procedure. Storing the result in a variable then using the variable as the parameter solves the problem.
Obviously this creates a simple workaround, but it is still a bug...
Could you please send a test program? (I mean program as in something that can be given to the compiler, without "..." and omissions, plus instructions how to invoke it if it expects arguments or interactive input. The usual stuff.)
Which platform, which GPC version?
Frank
I'm not in a position to offer a demo program, and unfortunately, this does not seem to happen in every situation, but here is in essence what
There seems to be a problem with using a function returning a string (maybe just one with no parameters?) directly as an argument to a procedure. Storing the result in a variable then using the variable as the parameter solves the problem.
Could you please send a test program? (I mean program as in something that can be given to the compiler, without "..." and omissions, plus instructions how to invoke it if it expects arguments or interactive input. The usual stuff.)
This may be difficult; the program in which I am experiencing the behavior is quite large, and I am trying to write something more manageable, but the bug is not readily reproduced in the smaller program. It may be a matter of something simple I am missing in the smaller program which triggers the bug, or perhaps it only occurs with programs beyond some minimal size, but I will continue trying. It may take some time though. (the procedures/functions in the existing program are complex and scattered across numerous units, so it may be that the unit structure is playing a part in this too?)
Which platform, which GPC version?
MacOS X; gpc --version reports:
bash-2.05a$ gpc --version gpc 20030830, based on gcc-3.3.2
(plus the copyright, etc.)
____________________________________________________________ Free 20 MB Bannerless Domain Hosting, 1000 MB Data Transfer 10 Personalized POP and Web E-mail Accounts, and more. Get It Now At www.doteasy.com
Frank D. Engel, Jr. wrote:
I'm not in a position to offer a demo program, and unfortunately, this does not seem to happen in every situation, but here is in essence what
There seems to be a problem with using a function returning a string (maybe just one with no parameters?) directly as an argument to a procedure. Storing the result in a variable then using the variable as the parameter solves the problem.
Could you please send a test program? (I mean program as in something that can be given to the compiler, without "..." and omissions, plus instructions how to invoke it if it expects arguments or interactive input. The usual stuff.)
This may be difficult; the program in which I am experiencing the behavior is quite large, and I am trying to write something more manageable, but the bug is not readily reproduced in the smaller program. It may be a matter of something simple I am missing in the smaller program which triggers the bug, or perhaps it only occurs with programs beyond some minimal size, but I will continue trying. It may take some time though. (the procedures/functions in the existing program are complex and scattered across numerous units, so it may be that the unit structure is playing a part in this too?)
This all may be the case. Just as well it may be a bug in your code (which, e.g. trashes some data which is only seen later). Hard to tell from outside.
All I can say is that I'm using string parameters and results a lot in my own code, also in combination, and I'm not aware of a specific problem like this ...
If it's possible for you, you can sent me the large code, and if I can reproduce the bug under Linux, DJGPP, Solaris or another system I use, I might be able to fix it.
Otherwise, you can wait until GPC gets range-checks (hopefully not too long), which might find the problem if it's an out-of-range access in your code (which is just one possibility, of course).
Frank
A good chunk of my code is currently MacOS X specific (not sure if it would work with GNUStep or not, but I rather doubt it at the moment), so it would be difficult to try using it on another platform.
This all may be the case. Just as well it may be a bug in your code (which, e.g. trashes some data which is only seen later). Hard to tell from outside.
I've considered this possibility, and I have had some issues similar to that while working with this code, but the problem I have mentioned has occurred at several different points in the program, and a bug of that nature would be showing up in other ways by now, I am quite certain. Additionally, the fix that I gave previously would indicate that the value is being correctly returned (since it is correctly assigned to the string variable), and that the procedure is correctly retrieving the value (since when using a variable, the correct data is accessed by the procedure). The problem only seems to be occurring when the name of the function is given directly in the procedure call; this may be occurring for function calls as well; I'm not sure yet. However, so far, this only seems to happen when the function returning the value has no arguments of its own, and using a temporary string to hold the value and handing the string variable to the procedure call instead of the direct result of the function call always seems to correct the problem. Note that in most of these cases, there is nothing between the assignment statement and the procedure (well, okay, there IS a semicolon...), so intervening statements should not be the cause of the problem.
All I can say is that I'm using string parameters and results a lot in my own code, also in combination, and I'm not aware of a specific problem like this ...
I have used GPC for a number of other projects, and have not had the problems before; I have been using it most recently under MacOS X, but have also used it on Solaris and IRIX (possibly Linux at one point; I can't remember really; I know I used FreePascal under DOS and Linux), and this is the first time I am experiencing these problems... of course, this is probably the largest program I have ever written in Pascal, or in any other language, for that matter.
The complete source tree, plus some extra files, is about 616K uncompressed; with the binaries, it bloats to over 3MB. I hesitate to send even just the source code over the list; if you have a private address you want the code on, eMail me offlist, but as I pointed out, this is largely MacOS X only right now.
If it's possible for you, you can sent me the large code, and if I can reproduce the bug under Linux, DJGPP, Solaris or another system I use, I might be able to fix it.
Otherwise, you can wait until GPC gets range-checks (hopefully not too long), which might find the problem if it's an out-of-range access in your code (which is just one possibility, of course).
As mentioned above...
----------------------------------------------------------- Frank D. Engel, Jr. fde101@fjrhome.net
____________________________________________________________ Free 20 MB Bannerless Domain Hosting, 1000 MB Data Transfer 10 Personalized POP and Web E-mail Accounts, and more. Get It Now At www.doteasy.com
Frank D. Engel, Jr. wrote:
I've considered this possibility, and I have had some issues similar to that while working with this code, but the problem I have mentioned has occurred at several different points in the program, and a bug of that nature would be showing up in other ways by now, I am quite certain. Additionally, the fix that I gave previously would indicate that the value is being correctly returned (since it is correctly assigned to the string variable), and that the procedure is correctly retrieving the value (since when using a variable, the correct data is accessed by the procedure). The problem only seems to be occurring when the name of the function is given directly in the procedure call; this may be occurring for function calls as well; I'm not sure yet. However, so far, this only seems to happen when the function returning the value has no arguments of its own, and using a temporary string to hold the value and handing the string variable to the procedure call instead of the direct result of the function call always seems to correct the problem. Note that in most of these cases, there is nothing between the assignment statement and the procedure (well, okay, there IS a semicolon...), so intervening statements should not be the cause of the problem.
Assignment to a temporary string is quite different, so it doesn't really exclude any possibility.
One thing to watch out for WRT strings is trashing the capacity field, whether in the function (the result variable) or the procedure (parameter), but that's just a wild guess. You may try, though, writing `foo.Capacity' at some points for debugging (where `foo' is `Result' or the declared result variable in the function, or the parameter name in the procedure).
I have used GPC for a number of other projects, and have not had the problems before; I have been using it most recently under MacOS X, but have also used it on Solaris and IRIX (possibly Linux at one point; I can't remember really; I know I used FreePascal under DOS and Linux), and this is the first time I am experiencing these problems... of course, this is probably the largest program I have ever written in Pascal, or in any other language, for that matter.
Unfortunately, this increases the chances for both kinds of bugs ...
The complete source tree, plus some extra files, is about 616K uncompressed; with the binaries, it bloats to over 3MB. I hesitate to send even just the source code over the list; if you have a private address you want the code on, eMail me offlist, but as I pointed out, this is largely MacOS X only right now.
You could use my private address as given in my signature, but as you say, if it only runs on MacOS X, I can't really do much with it (though maybe I'll notice something suspicious when looking at the source code). BTW, isn't it possible to separate the critical parts from the system specific code?
Perhaps Adrian or someone who is experienced with MacOS X and gdb can help trying to find out what exactly goes wrong ...
Frank
Frank Heckenbach wrote:
Frank D. Engel, Jr. wrote:
The complete source tree, plus some extra files, is about 616K uncompressed; with the binaries, it bloats to over 3MB. I hesitate to send even just the source code over the list; if you have a private address you want the code on, eMail me offlist, but as I pointed out, this is largely MacOS X only right now.
You could use my private address as given in my signature, but as you say, if it only runs on MacOS X, I can't really do much with it (though maybe I'll notice something suspicious when looking at the source code). BTW, isn't it possible to separate the critical parts from the system specific code?
Perhaps Adrian or someone who is experienced with MacOS X and gdb can help trying to find out what exactly goes wrong ...
Is there any news or help needed on this problem ?
Regards,
Adriaan van Os
In message 191D3ECD-533A-11D8-B051-0050E4BA750F@fjrhome.net, "Frank D. Engel, Jr." fde101@fjrhome.net writes
This may be difficult; the program in which I am experiencing the behavior is quite large, and I am trying to write something more manageable, but the bug is not readily reproduced in the smaller program.
I have experienced this problem of finding an apparent bug in a large piece of source code but being unable to write a test program to demonstrate it. My approach was to take the actual application and successively carve chunks out of it, checking whether the bug was still present. It took about half a day to do but did eventually end up with a small test program that enabled Frank to fix a bug.
I have experienced this problem of finding an apparent bug in a large piece of source code but being unable to write a test program to demonstrate it. My approach was to take the actual application and successively carve chunks out of it, checking whether the bug was still present. It took about half a day to do but did eventually end up with a small test program that enabled Frank to fix a bug.
I might try this; it may or may not happen today, but at some point in the near future, I will make a duplicate copy of my program, undo the 'workarounds', and start chopping away at it, to try to minimize the size of the program that still exhibits the unwanted behavior. If successful, I will send a reply to the list with my findings, and depending on the size of the remaining source code, just send it out (list if only a few K, otherwise to Frank's private address).
____________________________________________________________ Free 20 MB Bannerless Domain Hosting, 1000 MB Data Transfer 10 Personalized POP and Web E-mail Accounts, and more. Get It Now At www.doteasy.com
-
Adriaan van Os -
Frank D. Engel, Jr. -
Frank Heckenbach -
Martin Liddle