NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/c/19252

Text File | 1993-01-05 | 2.9 KB | 76 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!stanford.edu!nntp.Stanford.EDU!dkeisen
From: [e-mail] (Dave Eisen)
Subject: Re: Problem with string processing.
Message-ID: <[e-mail]>
Sender: ?@leland.Stanford.EDU
Organization: Sequoia Peripherals, Inc.
Date: Tue, 5 Jan 93 16:11:20 GMT
Lines: 65

In article <[e-mail]> [e-mail] (Ken McGlothlen) writes:
>Roy M. Silvernail ([e-mail]) writes:
>| [regarding the C statment:  while (*ptr++ = *str++);  ]
>|
>| (nice touch, BTW) How does this differ from 'strcpy(ptr, str)' besides the
>| function call overhead?
>It doesn't.  In fact, that's often how strcpy() is implemented.

In the example that Roy took this from, there is a big difference.
After the loop above, ptr points to the character one past the
trailing '\0' of the string. This is convenient because the function
it was taken from appended a character to the end of the string
and used this pointer to do so.

The loop is equivalent to:

   strcpy (ptr, str);
   ptr += strlen (str) + 1;

>| Assuming a large enough string for the append, and low-high byte ordering,
>| would this work?
>|
>| strcat(str,(char *)&ch);

>Well, it would work *sometimes*.  Remember that strcat() expects two pointers
>to ZERO-TERMINATED strings.  If what was stored in ch was immediately followed
>by a zero byte ('\0'), then it *would* work.  But ch is stored wherever the
>compiler wants to store it, and it could be followed by *anything*, which means
>that you could get a heck of a lot more characters on the end of str than you
>bargained for.

I think Roy was being cute here. I can never keep track of what
low-high byte order means or what different endianness means,
but I think what he is saying is that if ch is an int formed
by widening the character chr, ch is say 4 bytes that look
like:

   chr  '\0'   '\0'   '\0'

so the strcat would work because the byte containing the value
of ch *is* followed by '\0'.

It takes more than a byte order assumption to get this to work.
First of all, there is no rule that states an int is bigger
than a char; if they are the same size, your objection is
completely valid. And if chars happen to be the same as signed
chars, the widening from char to int must preserve value (using
ANSI semantics) so if the char happens to be negative (on a two's
complement system), the int ch looks like:

   chr   FFFF    FFFF   FFFF

and the strcat doesn't work either.

So Roy's trick, if I am understanding him correctly, will work
fine on a system where a number of assumptions are correct. I'll
let Roy defend the usage of his trick from those who would
argue it is not good style.


--
Dave Eisen                               Sequoia Peripherals: [phone]
[e-mail]              Home:                [phone]
       There's something in my library to offend everybody.
          --- Washington Coalition Against Censorship