jln@acns.nwu.edu (John Norstad) (07/10/90)
Disinfectant 2.0 has been released to the public - see comp.sys.mac.misc for details. I have also released the version 2.0 sample code. All of the code in Disinfectant except for the virus detection/repair "engine" is available to the public. Lots of people got the 1.0 sample code - the version 2.0 stuff is much improved. It's in MPW C 3.1. If you are interested, you can get a copy via anonymous FTP from acns.nwu.edu [129.105.49.1] in the pub/disinfectant directory. I can also email you a copy, but it's pretty big (8 big messages that you'll have to debinhex and join together with StuffIt). John Norstad Academic Computing and Network Services Northwestern University jln@acns.nwu.edu
ephraim@think.com (Ephraim Vishniac) (07/12/90)
In article <9510@accuvax.nwu.edu> jln@acns.nwu.edu (John Norstad) writes: >Disinfectant 2.0 has been released to the public - see comp.sys.mac.misc >for details. >I have also released the version 2.0 sample code. All of the code in >Disinfectant except for the virus detection/repair "engine" is available >to the public. Lots of people got the 1.0 sample code - the version 2.0 >stuff is much improved. It's in MPW C 3.1. I've ported the version 2.0 sample code to Think C 4.0. I've got the application itself working, but I haven't actually run the report building tools yet. If you're using Think C, watch for an announcement in a few days and save yourself a hefty amount of aggravation. I'll send the finished port to the usual places (sumex, rascal, the think-c archive @ ics.uci.edu) and maybe John will put up my version alongside his at acns.nwu.edu. Or maybe not - I haven't asked him yet. Aggravating things I found in this port: Think C doesn't define "normal" along with the text styles. OK, so the others are bit settings and normal = no bits set. Fine, I can live with that. Think C doesn't define osEvt, suspendResumeMessage, and other multifinder stuff. At least, not in the header files. If you look really hard, you can find them in CSwitchboard.c, which is a pretty strange place. (No reply from Rich Siegel on this one.) Think C doesn't use the prototype information if you give full prototypes for pointers to procedures. Instead, it attempts to infer the correct calling sequence from the actual parameters, sometimes with bogus results. Rich Siegel tells me that "this non-conformance will be addressed in the next version of the compiler." I don't know if he means 4.03 or 5.0. Equal time: MPW apparently defines the low memory globals as small integers. So, every use of them in John's code looks like this: *(actualType *)lowMemGlobal instead of just plain lowMemGlobal. I can't imagine why MPW does this, except perhaps to discourage the use of low memory globals. MPW does less stringent type checking. For example, it must not complain when you assign between (char *) and (unsigned char *), because John does this a lot. Think C gripes about this if you have pointer type checking turned on, which I always do. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.
hairston@henry.ece.cmu.edu (David Hairston) (07/16/90)
[jln@acns.nwu.edu (John Norstad) writes:] [N] Disinfectant 2.0 has been released to the public - see comp.sys.mac.misc [N] for details. [N] [N]I have also released the version 2.0 sample code. All of the code in [N] Disinfectant except for the virus detection/repair "engine" is available [N] to the public. Lots of people got the 1.0 sample code - the version 2.0 [N] stuff is much improved. It's in MPW C 3.1. [ephraim@think.com (Ephraim Vishniac) writes:] [V] I've ported the version 2.0 sample code to Think C 4.0. I've got the [V] application itself working, but I haven't actually run the report [V] building tools yet. If you're using Think C, watch for an [V] announcement in a few days and save yourself a hefty amount of [V] aggravation. I'll send the finished port to the usual places thanks John! kudos to Ephraim also!! i'll be looking for it. -dave- hairston@henry.ece.cmu.edu
tarr-michael@CS.YALE.EDU (michael tarr) (07/16/90)
Think C 4.01 also has a bug in strncpy: char s1[10]; char s2[20] = "A long string"; strncpy(s1, s2, 8); s1 will not have a '\0' appended to the end. So far as I can tell this is not per the standard definition. Also sizeof returns an int, but malloc and calloc require size_t! This is hidden on a none highlighted single line of text... Caused me great pain to find this... Mike Tarr tarr@cs.yale.edu
jbr0@cbnews.att.com (joseph.a.brownlee) (07/16/90)
In article <25571@cs.yale.edu> tarr-michael@CS.YALE.EDU (michael tarr) writes: >Think C 4.01 also has a bug in strncpy: > >char s1[10]; >char s2[20] = "A long string"; > >strncpy(s1, s2, 8); > >s1 will not have a '\0' appended to the end. So far as I can tell this >is not per the standard definition. Wrong. It should copy 8 characters from s2 to s1, period, which is exactly what it does. TC is correct. -- - _ Joe Brownlee, Analysts International Corp. @ AT&T Network Systems /_\ @ / ` 471 E Broad St, Suite 1610, Columbus, Ohio 43215 (614) 860-7461 / \ | \_, E-mail: jbr@cblph.att.com Who pays attention to what _I_ say? "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk
bruner@sp15.csrd.uiuc.edu (John Bruner) (07/16/90)
In article <25571@cs.yale.edu>, tarr-michael@CS (michael tarr) writes: >Think C 4.01 also has a bug in strncpy: > >strncpy(s1, s2, 8); > >s1 will not have a '\0' appended to the end. So far as I can tell this >is not per the standard definition. > >Also sizeof returns an int, but malloc and calloc require size_t! This >is hidden on a none highlighted single line of text... Caused me great >pain to find this... Here's the ANSI definition (section 4.11.2.4 "The strncpy function", from the December 7, 1988 draft): #include <string.h> char *strncpy(char *s1, const char *s2, size_t n) Description The strncpy function copies not more than n characters (characters that follow a null character are not copied) from the array pointed to by s2 to the array pointed to by s1.* If copying takes place between objects that overlap, the behavior is undefined. If the array pointed to by s2 is a string that is shorter than n characters, null characters are appended to the copy in the array pointed to by s1, until n characters in all have been written. Returns The strncpy function returns the value of s1. (footnote) Thus, if there is no null character in the first n characters of the array pointed to by s2, the result will not be null-terminated. This (essentially) has been the definition of strncpy() from its initial definition in UNIX (V7, I think, but my memory about this is a little hazy). This behavior comes from the original use for strncpy: filling fixed-length fields in UNIX data structures (e.g., 14-byte filenames in directory entries). Hence, it does not guarantee that the field will be null-terminated, but if it is too short, it may write more than one null character to fill out the destination. ANSI C (section 3.3.3.4) says that sizeof returns a value whose type is size_t. Thus, THINK C is not ANSI-compliant in its implementation of sizeof. This bug is very annoying, and I hope Symantec fixes it soon. -- John Bruner Center for Supercomputing R&D, University of Illinois bruner@csrd.uiuc.edu (217) 244-4476
lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) (07/17/90)
In article <25571@cs.yale.edu> tarr-michael@CS.YALE.EDU (michael tarr) writes: > >Think C 4.01 also has a bug in strncpy: > >char s1[10]; >char s2[20] = "A long string"; > >strncpy(s1, s2, 8); > >s1 will not have a '\0' appended to the end. So far as I can tell this >is not per the standard definition. ... >Mike Tarr >tarr@cs.yale.edu That's exactly the behavior I've always seen. According to the UPM: " string(3) The strcpy subroutine copies string s2 to s1, stopping after the null character has been copied. The strncpy subroutine copies exactly n characters, truncating s2 or adding null characters to s1 if necessary. The result will not be null-terminated if the length of s2 is n or more. Each function returns s1." Ken Lindahl lindahl@violet.berkeley.edu Advanced Technology Planning, Information Systems and Technology University of California at Berkeley
tarr-michael@CS.YALE.EDU (michael tarr) (07/17/90)
Well then MSC 5.0 is wrong. So is Berkeley 2.9. They both put the null there. Mike
ephraim@think.com (Ephraim Vishniac) (07/17/90)
In article <25571@cs.yale.edu> tarr-michael@CS.YALE.EDU (michael tarr) writes: >Think C 4.01 also has a bug in strncpy: >char s1[10]; >char s2[20] = "A long string"; >strncpy(s1, s2, 8); >s1 will not have a '\0' appended to the end. So far as I can tell this >is not per the standard definition. So far as I can tell, this is perfectly standard. I'm looking at the man pages for strncpy from Ultrix (DEC Unix for VAX) and Sun OS 4.0 and both warn that strncpy can produce unterminated strings. Sorry, I don't have the Think C libraries manual here, but I'd be amazed if it says anything different. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.
geh@mdavcr.UUCP (Graeme Hiebert) (07/25/90)
In article <40722@think.Think.COM> ephraim@think.com (Ephraim Vishniac) writes: ~In article <25571@cs.yale.edu> tarr-michael@CS.YALE.EDU (michael tarr) writes: ~>Think C 4.01 also has a bug in strncpy: ~> ... ~ ~So far as I can tell, this is perfectly standard. I'm looking at the ~man pages for strncpy from Ultrix (DEC Unix for VAX) and Sun OS 4.0 ~and both warn that strncpy can produce unterminated strings. Sorry, I ~don't have the Think C libraries manual here, but I'd be amazed if it ~says anything different. I don't know what the Think C manual says, but I do remember Borland's Reference Manual for Turbo C made a point of saying that strncpy does attach a null character on the end of the string, when it actually did not. @%$#!@!!! -g -- -------------------------------------------------------------------- Graeme Hiebert MacDonald Dettwiler, Richmond, BC, CANADA Phone: (604) 278-3411 Internet: geh%mdavcr@wimsey.bc.ca UUCP: ...uunet!van-bc!mdavcr!geh