Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!klaiber
From: klaiber@cs.washington.edu (Alexander Klaiber)
Newsgroups: comp.lang.eiffel
Subject: Re: Problems with STORABLE and C-packages
Message-ID: <9202@june.cs.washington.edu>
Date: 18 Sep 89 02:13:02 GMT
References: <9186@june.cs.washington.edu>
Reply-To: klaiber@june.cs.washington.edu.cs.washington.edu (Alexander Klaiber)
Organization: University of Washington, Computer Science, Seattle
Lines: 125
Keywords: storable, packages, bug, portability
Summary: BUG in _routines.c

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