The one who can't C

Discussion in 'C Programming' started by Henning, Aug 4, 2004.

  1. Henning

    Henning Guest

    Hi
    Problems translating C-code to Basic.
    Is unsigned char x; by default setting x to 0?

    /Henning
    --
    Time is present only to prevent everything from happening at once.
    Still it seems that everything happens at once.
    Then there must be a bug in time.
    To find the bug in time, isn't that what we all hope for.
    Henning, Aug 4, 2004
    #1
    1. Advertising

  2. Henning

    -berlin.de Guest

    Henning <> wrote:
    > Problems translating C-code to Basic.
    > Is unsigned char x; by default setting x to 0?


    It depends. If you define an automatic variable it's not initialized,
    i.e. if you have something like this

    int myfunction( char first_arg, int sec_arg )
    {
    unsigned char x;
    ...
    }

    then 'x' will have some random value (which might, just by luck, be 0).
    When you port code you may still have to keep in mind that on some
    platforms also such automatic variables get always initialized to 0
    and if the program is relying on that non-standard feature you will
    have to minimc this behavior.

    If, on the other hand, 'x' is a global variable (i.e. one that isn't
    defined within a function) then it will be initialized to 0.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
    -berlin.de, Aug 4, 2004
    #2
    1. Advertising

  3. Henning

    Henning Guest

    --
    Time is present only to prevent everything from happening at once.
    Still it seems that everything happens at once.
    Then there must be a bug in time.
    To find the bug in time, isn't that what we all hope for.
    <-berlin.de> skrev i meddelandet
    news:...
    > Henning <> wrote:
    > > Problems translating C-code to Basic.
    > > Is unsigned char x; by default setting x to 0?

    >
    > It depends. If you define an automatic variable it's not initialized,
    > i.e. if you have something like this
    >
    > int myfunction( char first_arg, int sec_arg )
    > {
    > unsigned char x;
    > ...
    > }
    >
    > then 'x' will have some random value (which might, just by luck, be 0).
    > When you port code you may still have to keep in mind that on some
    > platforms also such automatic variables get always initialized to 0
    > and if the program is relying on that non-standard feature you will
    > have to minimc this behavior.
    >
    > If, on the other hand, 'x' is a global variable (i.e. one that isn't
    > defined within a function) then it will be initialized to 0.
    >
    > Regards, Jens
    > --
    > \ Jens Thoms Toerring ___ -berlin.de
    > \__________________________ http://www.toerring.de


    The code is for an Atmel Risc MCU. I guess it is written in IAR's C4AVR.
    The var's are defined within functions, so I guess I have to look closer
    what is happening.
    Thx for helping!
    /Henning
    Henning, Aug 4, 2004
    #3
  4. [snips]

    On Tue, 03 Aug 2004 23:34:43 +0000, Jens.Toerring wrote:

    > It depends. If you define an automatic variable it's not initialized,
    > i.e. if you have something like this
    >
    > int myfunction( char first_arg, int sec_arg )
    > {
    > unsigned char x;
    > ...
    > }
    >
    > then 'x' will have some random value (which might, just by luck, be 0).


    Maybe I'm missing something; is there any guarantee that x will have _any_
    value whatsoever? Last I checked, attempting to take the value of an
    uninitialized variable was undefined behaviour; the implementation is
    perfectly within its rights to note that while there _will be_ an address
    reserved for x, there may not have yet been one reserved, hence an attempt
    to retrieve the value could merrily cause a crash.
    Kelsey Bjarnason, Aug 4, 2004
    #4
  5. Henning

    Richard Bos Guest

    Kelsey Bjarnason <> wrote:

    > On Tue, 03 Aug 2004 23:34:43 +0000, Jens.Toerring wrote:
    >
    > > It depends. If you define an automatic variable it's not initialized,
    > > i.e. if you have something like this
    > >
    > > int myfunction( char first_arg, int sec_arg )
    > > {
    > > unsigned char x;
    > > ...
    > > }
    > >
    > > then 'x' will have some random value (which might, just by luck, be 0).

    >
    > Maybe I'm missing something; is there any guarantee that x will have _any_
    > value whatsoever? Last I checked, attempting to take the value of an
    > uninitialized variable was undefined behaviour; the implementation is
    > perfectly within its rights to note that while there _will be_ an address
    > reserved for x, there may not have yet been one reserved, hence an attempt
    > to retrieve the value could merrily cause a crash.


    For normal types, yes. However, all possible unsigned char
    representations are required to be valid; there are no trap values in
    unsigned char.

    Richard
    Richard Bos, Aug 4, 2004
    #5
  6. Henning wrote:

    > Hi
    > Problems translating C-code to Basic.
    > Is unsigned char x; by default setting x to 0?
    >

    <snip>

    Perhaps you shouldn't be translating C to anything if you can't be
    bothered to pick up a book on C and at least take a glance at it.


    Mark F. Haigh
    Mark F. Haigh, Aug 4, 2004
    #6
  7. Henning

    CBFalconer Guest

    Richard Bos wrote:
    > Kelsey Bjarnason <> wrote:
    >> On Tue, 03 Aug 2004 23:34:43 +0000, Jens.Toerring wrote:
    >>
    >>> It depends. If you define an automatic variable it's not
    >>> initialized, i.e. if you have something like this
    >>>
    >>> int myfunction( char first_arg, int sec_arg )
    >>> {
    >>> unsigned char x;
    >>> ...
    >>> }
    >>>
    >>> then 'x' will have some random value (which might, just by
    >>> luck, be 0).

    >>
    >> Maybe I'm missing something; is there any guarantee that x will
    >> have _any_ value whatsoever? Last I checked, attempting to take
    >> the value of an uninitialized variable was undefined behaviour;
    >> the implementation is perfectly within its rights to note that
    >> while there _will be_ an address reserved for x, there may not
    >> have yet been one reserved, hence an attempt to retrieve the
    >> value could merrily cause a crash.

    >
    > For normal types, yes. However, all possible unsigned char
    > representations are required to be valid; there are no trap
    > values in unsigned char.


    I doubt whether it occurs anywhere, but while your assertion of no
    trap values is correct, there is no prohibition against other
    means of detecting uninitialized values. For example, every byte
    of storage could have an associated bit, reset on power-on, and
    set when anything is written into the byte. Think of a parity
    bit.

    --
    "I'm a war president. I make decisions here in the Oval Office
    in foreign policy matters with war on my mind." - Bush.
    "Churchill and Bush can both be considered wartime leaders, just
    as Secretariat and Mr Ed were both horses." - James Rhodes.
    "If I knew then what I know today, I would still have invaded
    Iraq. It was the right decision" - G.W. Bush, 2004-08-02
    CBFalconer, Aug 4, 2004
    #7
  8. Henning

    pete Guest

    CBFalconer wrote:
    >
    > Richard Bos wrote:
    > > Kelsey Bjarnason <> wrote:
    > >> On Tue, 03 Aug 2004 23:34:43 +0000, Jens.Toerring wrote:
    > >>
    > >>> It depends. If you define an automatic variable it's not
    > >>> initialized, i.e. if you have something like this
    > >>>
    > >>> int myfunction( char first_arg, int sec_arg )
    > >>> {
    > >>> unsigned char x;
    > >>> ...
    > >>> }
    > >>>
    > >>> then 'x' will have some random value (which might, just by
    > >>> luck, be 0).
    > >>
    > >> Maybe I'm missing something; is there any guarantee that x will
    > >> have _any_ value whatsoever? Last I checked, attempting to take
    > >> the value of an uninitialized variable was undefined behaviour;
    > >> the implementation is perfectly within its rights to note that
    > >> while there _will be_ an address reserved for x, there may not
    > >> have yet been one reserved, hence an attempt to retrieve the
    > >> value could merrily cause a crash.

    > >
    > > For normal types, yes. However, all possible unsigned char
    > > representations are required to be valid; there are no trap
    > > values in unsigned char.

    >
    > I doubt whether it occurs anywhere, but while your assertion of no
    > trap values is correct, there is no prohibition against other
    > means of detecting uninitialized values. For example, every byte
    > of storage could have an associated bit, reset on power-on, and
    > set when anything is written into the byte.


    That would be a trap representation.

    I discussed this matter on comp.std.c once,
    and my recollection was that the consensus was that
    you could read unitialised bytes as unsigned char,
    and from there it followed that reading an uninitialized
    unsigned char variable was merely unspecified behavior.

    --
    pete
    pete, Aug 4, 2004
    #8
  9. [snips]

    On Wed, 04 Aug 2004 15:57:12 +0000, pete wrote:

    > I discussed this matter on comp.std.c once,
    > and my recollection was that the consensus was that
    > you could read unitialised bytes as unsigned char,
    > and from there it followed that reading an uninitialized
    > unsigned char variable was merely unspecified behavior.


    I'd question that. Try this:

    unsigned char x,y;
    x = y;

    What prevents an implementation from simply not allocating space for y
    until it has been initialized - which would mean the code goes zot?

    This is a little different from say, using a pointer-to-byte to poke
    around memory (video memory, say), as it's assumed that the target region
    actually does exist and pointing the pointer at it initializes the pointer.

    Then we have this:

    double d[100];
    unsigned char *s = (unsigned char *)&d;

    Attempts to read *s, IMO, are at risk of a fault. Unlike the case of
    poking about in video memory, etc, there's no assurance that the memory
    for d has been allocated yet. Ponder the following in terms of the
    generated pseudo assembler:

    double d[100];
    unsigned char *s = (unsigned char *)&d;
    unsigned char c;
    c = *s;
    d[0] = 100.0;

    ..asm:

    data d ?
    data s ?
    data c ?

    addr1 <- addr d ; get address of d
    mlock , 4 ; assign space for s
    s <- addr1 ; store address of d in s
    mlock [c],1 ; assign space for c
    c <- (s) ; store value of *s in c
    mlock [d], 100 * 8 ; assign space for d

    That is, the system doesn't even _create_ a memory region for d until d is
    initialized; the attempt to view the contents of that region via c = *s is
    therefore trying to access memory which simply does not exist at all.

    Is there a reason an implementation cannot work this way?
    Kelsey Bjarnason, Aug 4, 2004
    #9
  10. Kelsey Bjarnason <> writes:
    > [snips]
    >
    > On Wed, 04 Aug 2004 15:57:12 +0000, pete wrote:
    >
    > > I discussed this matter on comp.std.c once,
    > > and my recollection was that the consensus was that
    > > you could read unitialised bytes as unsigned char,
    > > and from there it followed that reading an uninitialized
    > > unsigned char variable was merely unspecified behavior.

    >
    > I'd question that. Try this:
    >
    > unsigned char x,y;
    > x = y;
    >
    > What prevents an implementation from simply not allocating space for y
    > until it has been initialized - which would mean the code goes zot?


    There are at least some limitations on this kind of thing. The
    following is well-defined:

    unsigned char x;
    unsigned char *ptr = &x;
    *ptr = 42;

    x has to at least have a valid address before it's initialized.
    Conceivably there needn't be any memory there, but if there isn't then
    the memory has to be allocated *at that address* on the first
    assignment.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Aug 5, 2004
    #10
  11. Henning

    CBFalconer Guest

    pete wrote:
    > CBFalconer wrote:
    >> Richard Bos wrote:
    >>>

    .... snip ...
    >>>
    >>> For normal types, yes. However, all possible unsigned char
    >>> representations are required to be valid; there are no trap
    >>> values in unsigned char.

    >>
    >> I doubt whether it occurs anywhere, but while your assertion of no
    >> trap values is correct, there is no prohibition against other
    >> means of detecting uninitialized values. For example, every byte
    >> of storage could have an associated bit, reset on power-on, and
    >> set when anything is written into the byte.

    >
    > That would be a trap representation.
    >
    > I discussed this matter on comp.std.c once,
    > and my recollection was that the consensus was that
    > you could read unitialised bytes as unsigned char,
    > and from there it followed that reading an uninitialized
    > unsigned char variable was merely unspecified behavior.


    As I said, and you snipped, think of a parity bit. Use of such
    would give a 50% chance of a bad parity interrupt on reading any
    byte in any manner in any language (including C) before
    initialization. There is no reason the hardware should not have
    the equivalent to detect reads from uninitialized storage. Such
    hardware (parity) exists, and is quite common, although now
    superseded by ECC in general. The standards were never intended
    to preclude normal hardware.

    --
    "I'm a war president. I make decisions here in the Oval Office
    in foreign policy matters with war on my mind." - Bush.
    "Churchill and Bush can both be considered wartime leaders, just
    as Secretariat and Mr Ed were both horses." - James Rhodes.
    "If I knew then what I know today, I would still have invaded
    Iraq. It was the right decision" - G.W. Bush, 2004-08-02
    CBFalconer, Aug 5, 2004
    #11
  12. Henning

    pete Guest

    CBFalconer wrote:
    >
    > pete wrote:
    > > CBFalconer wrote:
    > >> Richard Bos wrote:
    > >>>

    > ... snip ...
    > >>>
    > >>> For normal types, yes. However, all possible unsigned char
    > >>> representations are required to be valid; there are no trap
    > >>> values in unsigned char.
    > >>
    > >> I doubt whether it occurs anywhere, but while your assertion of no
    > >> trap values is correct, there is no prohibition against other
    > >> means of detecting uninitialized values. For example, every byte
    > >> of storage could have an associated bit, reset on power-on, and
    > >> set when anything is written into the byte.

    > >
    > > That would be a trap representation.
    > >
    > > I discussed this matter on comp.std.c once,
    > > and my recollection was that the consensus was that
    > > you could read unitialised bytes as unsigned char,
    > > and from there it followed that reading an uninitialized
    > > unsigned char variable was merely unspecified behavior.

    >
    > As I said, and you snipped, think of a parity bit.


    I know unsigned char as having only value bits.

    --
    pete
    pete, Aug 5, 2004
    #12
  13. Henning

    CBFalconer Guest

    pete wrote:
    >
    > CBFalconer wrote:
    > >
    > > pete wrote:
    > > > CBFalconer wrote:
    > > >> Richard Bos wrote:
    > > >>>

    > > ... snip ...
    > > >>>
    > > >>> For normal types, yes. However, all possible unsigned char
    > > >>> representations are required to be valid; there are no trap
    > > >>> values in unsigned char.
    > > >>
    > > >> I doubt whether it occurs anywhere, but while your assertion of no
    > > >> trap values is correct, there is no prohibition against other
    > > >> means of detecting uninitialized values. For example, every byte
    > > >> of storage could have an associated bit, reset on power-on, and
    > > >> set when anything is written into the byte.
    > > >
    > > > That would be a trap representation.
    > > >
    > > > I discussed this matter on comp.std.c once,
    > > > and my recollection was that the consensus was that
    > > > you could read unitialised bytes as unsigned char,
    > > > and from there it followed that reading an uninitialized
    > > > unsigned char variable was merely unspecified behavior.

    > >
    > > As I said, and you snipped, think of a parity bit.

    >
    > I know unsigned char as having only value bits.


    A parity bit is an extra bit whose value is calculated from all
    the other bits on write. It may describe odd or even parity. On
    read, the parity is again calculated, and if it doesn't match a
    hardware error has been detected. The result should be a system
    interrupt.

    Todays systems, when they have not been cheapened by eliminating
    the feature, have replaced parity with ECC, which uses a set of
    syndrome bits over a wider word to automatically correct one bit
    errors, and detect multiple bit errors.

    Since memory errors can be due to actual hardware failure, usually
    repeatable, or external events (such as noise, or cosmic rays, or
    alpha particles) that are not repeatable, it is foolish to
    eliminate ECC checking on the memory system. Unfortunately the
    majority of PCs sold today have done just that, and are inherently
    untrustworthy.

    All of this is transparent to the code using the memory. It
    doesn't know it is there.

    --
    "I'm a war president. I make decisions here in the Oval Office
    in foreign policy matters with war on my mind." - Bush.
    "Churchill and Bush can both be considered wartime leaders, just
    as Secretariat and Mr Ed were both horses." - James Rhodes.
    "If I knew then what I know today, I would still have invaded
    Iraq. It was the right decision" - G.W. Bush, 2004-08-02
    CBFalconer, Aug 5, 2004
    #13
  14. Henning

    Chris Torek Guest

    >Kelsey Bjarnason <> writes:
    >> What prevents an implementation from simply not allocating space for

    [an object of type char and named]
    >> y until it has been initialized ...


    In article <news:>
    Keith Thompson <> writes:
    >There are at least some limitations on this kind of thing. The
    >following is well-defined:
    >
    > unsigned char x;
    > unsigned char *ptr = &x;
    > *ptr = 42;
    >
    >x has to at least have a valid address before it's initialized.
    >Conceivably there needn't be any memory there, but if there isn't then
    >the memory has to be allocated *at that address* on the first
    >assignment.


    Moreover, whether or not x (in Keith's code) or y is initialized,
    two different pointers to the object must compare equal -- e.g.:

    unsigned char *ptr = &x;
    ...
    unsigned char *p2 = &x;
    *ptr = 42;
    unsigned char *p3 = &x; // assuming C99; or add a block
    assert(ptr == &x);
    assert(ptr == p2);
    assert(ptr == p3);

    I think it would be "challenging", to say the least, to make an
    implementation work with lazy allocation.

    Note also that it is legal to do things like:

    struct with_holes x, y;
    ... /* set up all the fields in x */
    memcpy(&y, &x, sizeof y);

    where the (compiler-allocated) "holes" inside x are never initialized.
    The memcpy() call accesses the uninitialized bytes within the object
    x, copying their bitwise representations to the object y, even if
    those bit patterns are "trap representations" when considered as
    something other than "unsigned char"s.

    Of course, there is no guaranteed way to produce holes -- bitfields
    are perhaps the closest, using unnamed :0 fields to force alignment,
    but even this operation is up to the implementation -- so if one
    really wanted to work at a perverse implementation (for the
    DeathStation 9000 perhaps), there might be some way to obey the
    "letter of the law" of the Standard while violating the spirit. :)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Aug 5, 2004
    #14
  15. On Wed, 4 Aug 2004 01:20:12 +0200, "Henning"
    <> wrote:

    >Hi
    >Problems translating C-code to Basic.
    >Is unsigned char x; by default setting x to 0?


    if it is *out* every function or procedure (global):
    YES you have to set x=0
    if it is *in* any function or procedure
    if there is
    "static unsigned char x;" then you have to set x=0
    else you can set x=0 or not;
    ---------------------------------------------
    I would say if you see "unsigned char x;" set always x=0.
    RoSsIaCrIiLoIA, Aug 10, 2004
    #15
  16. RoSsIaCrIiLoIA <> wrote in message news:<>...
    > On Wed, 4 Aug 2004 01:20:12 +0200, "Henning"
    > <> wrote:


    > >Problems translating C-code to Basic.
    > >Is unsigned char x; by default setting x to 0?


    <sigh> could you (RoSsIaCrIiLoIA) check your posts for correctness
    *before*
    you post them. Since I'm criticising someone this ensures this post
    will
    have at least one error...

    > if it is *out* every function or procedure (global):
    > YES you have to set x=0


    if it outside any function (has file scope) then no you don't have to
    initialise it as the compiler automatically initialises it to
    0 (zero). Note C has no "procedures".

    > if it is *in* any function or procedure
    > if there is
    > "static unsigned char x;" then you have to set x=0
    > else you can set x=0 or not;


    If it is inside a function and is marked "static" then no you don't
    have to initialise it as the compiler automatically initialises it to
    0 (zero). This
    is only true the first time the function is called, any changes made
    are permenent.

    If it is inside a function and is not marked "static" then it is
    automatic
    variable and it is not initialised.

    > I would say if you see "unsigned char x;" set always x=0.


    unless, that is, you want it initialised to something else...


    --
    Nick Keighley
    Nick Keighley, Aug 11, 2004
    #16
  17. On 11 Aug 2004 02:07:58 -0700, (Nick
    Keighley) wrote:
    >RoSsIaCrIiLoIA <> wrote in message news:<>...
    >> On Wed, 4 Aug 2004 01:20:12 +0200, "Henning"
    >> <> wrote:

    >

    ******************************************
    >> >Problems translating C-code to Basic.

    ^^^^^^^^^^^^^^^
    ******************************************
    >> >Is unsigned char x; by default setting x to 0?

    >
    ><sigh> could you (RoSsIaCrIiLoIA) check your posts for correctness
    >*before*
    >you post them. Since I'm criticising someone this ensures this post
    >will
    >have at least one error...
    >
    >> if it is *out* every function or procedure (global):
    >> YES you have to set x=0

    >
    >if it outside any function (has file scope) then no you don't have to
    >initialise it as the compiler automatically initialises it to
    >0 (zero).


    you speak about *translation* from C to Basic? Right? In this contest
    if you want to translate from C to Basic this:
    unsigned char x;

    that is *out* functions and procedure then YOU
    (or the Basic compiler) have to initialise the 'x translation' in
    Basic to 0. Because like you say "the [C] compiler automatically
    initialises it to 0 (zero)." That is what I have said (but perhaps it
    was not so clear, excuse me)
    I don't know where Basic compiler initialises them to zero.

    >Note C has no "procedures".

    unsigned a;
    void proced(void){++a;}

    Does it seem a function?
    RoSsIaCrIiLoIA, Aug 11, 2004
    #17
  18. RoSsIaCrIiLoIA wrote on 11/08/04 :
    >> Note C has no "procedures".

    > unsigned a;
    > void proced(void){++a;}
    >
    > Does it seem a function?


    It *is* a function. You know, C is not Pascal.

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

    "C is a sharp tool"
    Emmanuel Delahaye, Aug 11, 2004
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Randall Parker
    Replies:
    0
    Views:
    1,623
    Randall Parker
    Dec 4, 2005
  2. Sanjay Meher
    Replies:
    4
    Views:
    402
    Jon A. Cruz
    Feb 8, 2004
  3. news.frontiernet.net
    Replies:
    6
    Views:
    1,107
    news.frontiernet.net
    Apr 16, 2004
  4. loveNUNO
    Replies:
    2
    Views:
    896
    loveNUNO
    Nov 20, 2003
  5. Merciadri Luca
    Replies:
    4
    Views:
    800
Loading...

Share This Page