Related articles |
---|
Different string format options, benefits? coxs2@rpi.edu (Sean C. Cox) (1991-10-16) |
Re: Different string format options, benefits? pardo@cs.washington.edu (1991-10-17) |
Re: Different string format options, benefits? pk@cs.tut.fi (1991-10-18) |
Re: Different string format options, benefits? agulbra@Siri.Unit.NO (1991-10-18) |
Re: Different string format options, benefits? db@dcs.ed.ac.uk (Dave Berry) (1991-10-20) |
Re: Different string format options, benefits? tm@well.sf.ca.us (1991-10-22) |
Re: Different string format options, benefits? buzzard@eng.umd.edu (1991-10-25) |
Re: Different string format options, benefits? henry@zoo.toronto.edu (1991-10-25) |
[2 later articles] |
Newsgroups: | comp.compilers |
From: | pardo@cs.washington.edu (David Keppel) |
Keywords: | code, C |
Organization: | Computer Science & Engineering, U. of Washington, Seattle |
References: | 91-10-061 |
Date: | Thu, 17 Oct 91 19:21:32 GMT |
Sean C. Cox <coxs2@rpi.edu> writes:
>[Tradeoffs of <size,bytes> vs <bytes,null> representation?]
For arbitrary-length strings, you need an address-sized length field (2
or 4 bytes). For null termination, you need only a single (null) byte.
Note alignment considerations.
For strcpy/strcmp operations you can use the value being read to detect
termination, rather than keeping both a count and a current character.
Despite that, strcmp and strcpy may be more efficient using a count.
Some systems have inter-language compatablity by keeping both a length
(in the byte or bytes preceding the initial address) and a null char
just after the last string character.
;-D on ( All string out ) Pardo
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.