Re: difference between casting and atol,atoi functions

From: Peter Nilsson (airia_at_acay.com.au)
Date: 02/15/05


Date: 14 Feb 2005 21:56:13 -0800


[There's no need to cross post this to two different groups.]

Janice wrote:
> unsigned char buf[255];
> signed long* x;
> signed long y;
> buf[0]=255;
> buf[1]=255;
> buf[2]=255;
> buf[3]=255;
> //statment 1
> x=(signed long*)buf;
> //statement 2
> y=atol(buf,4);
>
> What is the difference between statement 1 and 2?

None. They both invoke undefined behaviour.

The first is ill-formed since buf may not be suitably
aligned for a signed long, and it may represent a trap
representation in anycase. [Casts are usually an error
and should be avoided.]

The second is ill-formed since buf may not be null
byte terminated, as a string should be. Consequently,
atol() may not be able to convert it. Secondly, the
character code 255 need not represent a digit
character. [In fact, it's unlikely to.]

What you're doing is viewing a byte sequence as one
of two forms. Either a long integer (1), or a text string
description (2). The difference is analogous to trying
to read '1234' as a series of English 'words', or trying
to read 'one thousand...' as a number.

A better example might be...

  #include <stdio.h>
  #include <stdlib.h>

  void dump(const void *p, size_t n)
  {
    const unsigned char *uc = p;
    while (n--) printf(" 0x%02X", 0u + *uc++);
  }

  int main(void)
  {
    long x = 1234;
    long y, z;
    char buf[42]; /* 42 is known to be big enough here */
    unsigned char *mem = malloc(sizeof x);

    printf("long: x = %ld\n", x);

    printf("\nbyte sequence at &x: ");
    dump(&x, sizeof x);
    putchar('\n');

    if (mem)
    {
      memcpy(mem, &x, sizeof x);
      y = * (long *) mem;
      printf("interpreted byte sequence: y = %ld\n", y);
    }

    sprintf(buf, "%ld", x);
    printf("\nx as a string: buf = \"%s\"\n", buf);

    z = atol(buf);
    printf("string back to long: z = %ld\n", z);

    return 0;
  }

Note that the size and representation of a signed long can
(and does) differ from machine to machine. Also note that
a non null return value from malloc will be suitably
aligned for any type.

-- 
Peter


Relevant Pages

  • Re: difference between casting and atol,atoi functions
    ... The first is ill-formed since buf may not be suitably ... character code 255 need not represent a digit ... or a text string ... Note that the size and representation of a signed long can ...
    (comp.lang.c)
  • Re: Unicode question
    ... Obviously not for the representation in memory;-) ... They fit your approach to string handling. ... character encoding, or in the average or precise display width of the ... Since UTF-16 chars can be 2 or 4 bytes, one has to be always alert ...
    (borland.public.delphi.non-technical)
  • Re: Strings and bindary data
    ... String to another file, are those files guaranteed to be identical? ... No. Strings are designed to hold textual data, and that /always/ is subject to ... beyond what is in its representation. ... representation -- that's to say a mapping from abstract characters (or ...
    (comp.lang.java.programmer)
  • Re: Why (0.09+0.01-0.1) is not equal to 0.09+0.01-0.1 ?
    ... However less precision would suffice, since 17 digits would uniquely identify an IEEE double precision binary representation. ... Function D2BAs String ... You can use the VBA Decimal data type to carry 28 figures, but you have to be careful to avoid truncation in type conversions and to avoid overflow or underflow since the Decimal data type has fixed precision with no scientific notation. ...
    (microsoft.public.excel)
  • Re: Schrodingers Equation
    ... string and how they are connected elastically to their neighbors. ... understand the motion of the string in terms of the motions of the ... An alternative representation is as the collective ... the wave on string can be abstracted as a single pendulum. ...
    (sci.physics.research)