klaiber@cs.washington.edu (Alexander Klaiber) (09/15/89)
Aaarghhhh... I have been playing around with the C_PACKAGE recently in order to port one application I wrote from the Sun (which is running Eiffel) to a VAX (which is not running Eiffel, hence the C_PACKAGE fuss). I am using the STORABLE class to generate a complicated data structure that gets read by another module later on. Now things are just fine on our Sun; however, when I try to run the ported code on the VAX, I get either a crash or nothing at all during the 'retrieve' operation. Has anyone had this kind of a portability problem before? And if so, have you found a solution? Oh yes, I am still using 2.1. Frustrated, Alexander Klaiber -- Alexander Klaiber klaiber@cs.washington.edu
klaiber@cs.washington.edu (Alexander Klaiber) (09/18/89)
In article <9186@june.cs.washington.edu> I wrote about problems porting
an application using STORABLE from a SUN-3 to a VAX.
Thanks to all the people who responded to my mail; for those who are
interested in a summary: one other person had similar problems to mine
whereas another apparently had no trouble at all porting even rather
complex STORABLE objects.
Well, I finally got it to run after all --- I threw in a few ".duplicate"
operations (for strings) in random places and all of a sudden, it worked.
I still do not, however, understand *why* --- shared objects in the stored
structure should not have been a problem at all! Also, it worked just fine
on the SUN after all, in many test runs with all kinds of data, whereas on
the VAX, I *reliably* got crashes.
Since the program now runs, the pressure of a deadline is off, so I'll try
and spend some more time on figuring out possible reasons... if I get any
results, I'll post.
Oh yes, some people wanted to know my exact environment:
Development was on a SUN-3 under Sun UNIX 4.2 Release 3.3,
the target was a VAX 8550 under Ultrix-32 V3.0 (Rev 63),
PRECONDITIONS, ALL_ASSERTIONS, DEBUG and GARBAGE_COLLECION were all on,
OPTIMIZE was left off (on both SUN and VAX (c-package) versions).
On another note: Here's an interesting little portability problem -- or
actually, more likely just a plain bug. (I ran into this one a couple of
days ago in my frantic struggle to get the thing working on our VAX).
Consider this program:
class Bug
inherit
STD_FILES
feature
blanks:String is
once
Result := " \t";
end; --blanks
Create is
local
i:integer;
res : integer;
do
readstring(42);
from
i := 1;
until
i>laststring.length
loop
putchar(laststring.entry(i));
putstring(": ");
res := blanks.search_char(laststring.entry(i),1);
putint(res);
new_line;
i := i + 1;
end;
end; --Create
end; --class
which is supposed to find blanks and tabs in a string. Given the input
"x \t" (letter 'x', blank, tab), it should print
x: 0
: 1
: 2
However, on the VAX described above, we get
x: 0
: 0
: 2
Now while you read the code above, let me try and find the exact cause
and a possible fix...
Okay, I am back (I *won't* tell you how much time this took me!)...
The problem is in function "c_search_char", file "_routines.c", line 224.
Change
while ((c != *t) && *t++);
if (*(t - 1) == '\0') return (0);
return (t - s + 1);
to
while ( (c==*t) ? ++t,0 : *t++ );
if (*(t - 1) == '\0') return (0);
return (t - s);
The original definition will only work if
(1) either '&&' is compiled strict (i.e. both args are evaluated in any
case) --- I don't know of a compiler that does that and to my
knowledge, that would be counter to the "official" definition of "&&"
in Kernighan&Ritchie
(2) Wherever your friendly operating system puts the actual string
(" \t" in this case for feature "blanks"), it makes sure that the
string is preceded by a non-null character --- this seems to be the
case with our SUN operations system, at least most of the time!
If the above conditions are not satisfied AND the character you're looking
for is the first one in the string, then "c_search_char" will try and
reference the memory-location just *before* the actual string (in the
second line of the fragment above). If the (random) byte in there just
happens to be a zero, then the "return(0)" exit is falsely taken!
Now I guess our Ultrix does zero-fill of new memory pages, so the
likelihood of the error occuring seems to be larger.
Sooooo... you guys at Interactive listening? Have you fixed this in Eiffel
2.2 yet? Could you maybe comb through the rest of your runtime system for
similar strange things? Actually, I recommend compiling a few programs
with "gcc" (the GNU compiler, preferably 1.34 or higher) and turn on
warnings (-Wall); it makes for rather interesting effects...
and remember:
"C gives you all the power of assembler...
along with the portability of assembler!" -- unknown
Alexander Klaiber
klaiber@cs.washington.edu
--
Alexander Klaiber
klaiber@cs.washington.edu