[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

1005.0. "Warning: don't write your own bcopy()!!" by SARAH::HAINSWORTH (My fingers never leave my hands!) Thu Jun 22 1989 16:08

Since both I (DECwrite Equation Editor developer) and the DECchart development
team committed this blunder, I figured I ought to warn all you C developers 
out there.  That way the toolkit folks won't want to strangle you, too :-).

I developed my application on Ultrix, and when I tried to link my source on
VMS I found out that bcopy() was missing.  Since I wanted to keep common source
between VMS and Ultrix, I quickly wrote up my own bcopy(), linked it, and it
ran fine.  When I copied this source back to Ultrix, however, (months later)
the code died deep within the toolkit code at the first DrmFetchWidget().
The problem is that the "real" bcopy intelligently handles all possible 
combinations of overlapping source and destination data areas, and I'd missed 
one.  So if your code dies in DRMFetchWidget() or XtRealizeWidget(), look to 
see if you've redefined any library routines.

-John

T.R	Title	User	Personal Name	Date	Lines
1005.1	Watch out for memcpy on ULTRIX	HANNAH::MESSENGER	Bob Messenger	`Thu Jun 22 1989 17:05`	18
	Re: .0 Related problem (I'm ashamed to admit this since Vince will read this!): don't convert the bcopy's to memcpy's, because on ULTRIX memcpy doesn't check for overlapping sources and destinations. I changed DECterm's bcopy's to memcpy's so I could link with just the standard VAXCRTL on VMS, but later on it broke when I tried to run it on ULTRIX. My latest solution is: #ifdef VMS #define COPY( d, s, n ) memcpy( d, s, n ) #else #define COPY( d, s, n ) bcopy( s, d, n ) #endif (Note that the first two operations are reversed between memcpy and bcopy.) -- Bob
1005.2	No problem	TLE::DANIELS	Brad Daniels, VAX C RTL whipping boy	`Fri Jun 23 1989 17:17`	7
	Actually, this is not a failing in Ultrix. The problem is that memcpy() on VMS is an over-achiever. According to ANSI, only memmove() needs to check for overlap (it is equivalent to bcopy()). The memcpy() function doesn't have to check for overlap, meanin it can be faster on many architectures. - Brad
1005.3		KONING::KONING	NI1D @FN42eq	`Tue Jun 27 1989 15:47`	7
	...but of course on VAXen the string move instruction does the overlap check itself, so there doesn't seem to be any rational reason for any data move routine to work any other way unless it is REQUIRED to work that way. paul
1005.4		TLE::DANIELS	Brad Daniels, VAX C RTL whipping boy	`Tue Jun 27 1989 16:22`	4
	... Unless it has to deal with more than 65535 characters... - Brad
1005.5	Could use the RTL	QUARK::LIONEL	B - L - Oh, I don't know!	`Tue Jun 27 1989 16:59`	5
	OTS$MOVE3 and OTS$MOVE5 were written for VMS for just this purpose. They will do moves of up to 2**30 characters and handle overlaps properly. Steve
1005.6	Re .-1:	TLE::DANIELS	Brad Daniels, VAX C RTL whipping boy	`Tue Jun 27 1989 18:31`	2
	What do you think memmove() does? 8*}