Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The one who can't C

Reply
Thread Tools

The one who can't C

 
 
Henning
Guest
Posts: n/a
 
      08-03-2004
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.


 
Reply With Quote
 
 
 
 
Jens.Toerring@physik.fu-berlin.de
Guest
Posts: n/a
 
      08-03-2004
Henning <(E-Mail Removed)> 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 ___ http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de
\__________________________ http://www.toerring.de
 
Reply With Quote
 
 
 
 
Henning
Guest
Posts: n/a
 
      08-03-2004


--
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.
<(E-Mail Removed)-berlin.de> skrev i meddelandet
news:(E-Mail Removed)...
> Henning <(E-Mail Removed)> 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 ___ (E-Mail Removed)-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


 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      08-04-2004
[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.


 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      08-04-2004
Kelsey Bjarnason <(E-Mail Removed)> 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
 
Reply With Quote
 
Mark F. Haigh
Guest
Posts: n/a
 
      08-04-2004
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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-04-2004
Richard Bos wrote:
> Kelsey Bjarnason <(E-Mail Removed)> 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

 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      08-04-2004
CBFalconer wrote:
>
> Richard Bos wrote:
> > Kelsey Bjarnason <(E-Mail Removed)> 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
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      08-04-2004
[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 [s], 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?


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-05-2004
Kelsey Bjarnason <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can one declare more than one signal on one line? Merciadri Luca VHDL 4 11-01-2010 02:00 PM
Nike air force one, air force 1, air force one low cut, air force one abdul_razak@indiatimes.com Digital Photography 2 12-31-2008 04:29 PM
Samsung SCD6040 - Anyone have one, used one, or have reviews on one? g wills Digital Photography 0 09-08-2004 08:06 PM
CSS aligning two things on one line with one left and one right news.frontiernet.net HTML 6 04-16-2004 02:44 AM
Using One XSLT and multiple XML Problem (One is XML and another one is XBRL) loveNUNO XML 2 11-20-2003 06:47 AM



Advertisments