twitter: comp.lang.c - 12 new messages in 5 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* 'static' : strange behavior - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/f36bdf2a603ed11b?hl=en
* How to check whether malloc has allocated memory properly in case if malloc(
0) can return valid pointer - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/b637a7ebdebcf3b1?hl=en
* EXTORADINARY HOT PHOTOS - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/06514e452847f477?hl=en
* Binary Search in C - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/dac735d08655358b?hl=en
* Getting a runtime error::"The instruction at 0x004010b4 referenced memory at
0x00000000. The memory could not be read - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e42df39e73323505?hl=en

==============================================================================
TOPIC: 'static' : strange behavior
http://groups.google.com/group/comp.lang.c/t/f36bdf2a603ed11b?hl=en
==============================================================================

== 1 of 6 ==
Date: Mon, Dec 27 2010 6:43 pm
From: Ian Collins

On 12/28/10 03:24 PM, Mark wrote:
> Eric Sosman wrote:
>> Yes, a `static' variable retains its last-stored[*] value from
>> one function call to the next, or more generally from one assignment
>> to the next. If there has been no assignment, the `static' variable
>> holds it initialization value, or "the right kind of zero" if there
>> is no initializer. Based on what you've shown, `nvram_status' should
>> have the value minus one the first time nvram_init() is called. I
>> therefore suspect that you have not shown everything that's relevant.
>> In particular, you haven't shown how you determine the original value
>> of `nvram_status' -- and it's possible that the determination itself
>> might be at fault.
>
> I print the value of 'nvram_status', below is more complete snippet:
>
> int nvram_init (void *si)
> {
> int ret;
> static int nvram_status = -1;
>
> printf("%s : nvram_status=%d\n", __FUNCTION__, nvram_status); /* my line */
>
> if (nvram_status == 1) /* the very first statement in the original code */
> return 1;

Why do you set the value to -1 and test for 1?

--
Ian Collins

== 2 of 6 ==
Date: Mon, Dec 27 2010 6:46 pm
From: "Mark"

Ian Collins wrote:
>> int nvram_init (void *si)
>> {
>> int ret;
>> static int nvram_status = -1;
>>
>> printf("%s : nvram_status=%d\n", __FUNCTION__, nvram_status); /* my
>> line */
>>
>> if (nvram_status == 1) /* the very first statement in the original
>> code */ return 1;
>
> Why do you set the value to -1 and test for 1?

I don't; as I mentioned earlier this is not my code.

--
Mark

== 3 of 6 ==
Date: Mon, Dec 27 2010 6:50 pm
From: Eric Sosman

On 12/27/2010 9:24 PM, Mark wrote:
> Eric Sosman wrote:
>> Yes, a `static' variable retains its last-stored[*] value from
>> one function call to the next, or more generally from one assignment
>> to the next. If there has been no assignment, the `static' variable
>> holds it initialization value, or "the right kind of zero" if there
>> is no initializer. Based on what you've shown, `nvram_status' should
>> have the value minus one the first time nvram_init() is called. I
>> therefore suspect that you have not shown everything that's relevant.
>> In particular, you haven't shown how you determine the original value
>> of `nvram_status' -- and it's possible that the determination itself
>> might be at fault.
>
> I print the value of 'nvram_status', below is more complete snippet:
>
> int nvram_init (void *si)
> {
> int ret;
> static int nvram_status = -1;
>
> printf("%s : nvram_status=%d\n", __FUNCTION__, nvram_status); /* my line */
>
> if (nvram_status == 1) /* the very first statement in the original code */
> return 1;
>
> /* low-level initializations of NVRAM */
> /* nvram_status can be altered down here */
> ...
> }

It seems you like to dispense information drop by precious drop,
one tiny tidbit at a time. If the information is so very private that
you dare not share it except in meaningless driblets -- well, I have
never been known as a patient man, and I think I've got better things
to do than spend time wheedling details from a coy Twenty Questions
player.

If and when you want help from me, provide sufficient information
to get my analysis started. Until then, I've got more pressing matters
to attend to -- it's been *ages* since I last plucked my eyebrows.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 4 of 6 ==
Date: Mon, Dec 27 2010 8:04 pm
From: Shivanand Kadwadkar

On Dec 28, 7:24 am, "Mark" <mark_cruzNOTFORS...@hotmail.com> wrote:
> Eric Sosman wrote:
> > Yes, a `static' variable retains its last-stored[*] value from
> > one function call to the next, or more generally from one assignment
> > to the next. If there has been no assignment, the `static' variable
> > holds it initialization value, or "the right kind of zero" if there
> > is no initializer. Based on what you've shown, `nvram_status' should
> > have the value minus one the first time nvram_init() is called. I
> > therefore suspect that you have not shown everything that's relevant.
> > In particular, you haven't shown how you determine the original value
> > of `nvram_status' -- and it's possible that the determination itself
> > might be at fault.
>
> I print the value of 'nvram_status', below is more complete snippet:
>
> int nvram_init (void *si)
> {
> int ret;
> static int nvram_status = -1;
>
> printf("%s : nvram_status=%d\n", __FUNCTION__, nvram_status); /* my
> line */
>
> if (nvram_status == 1) /* the very first statement in the original code
> */
> return 1;
>
> /* low-level initializations of NVRAM */
> /* nvram_status can be altered down here */
> ...
>
> }
> > [*] For a `volatile' variable, "last-stored" might not be a
> > visible action of the program: a hardware clock or some such might
> > "store" a new value in the variable without an explicit assignment by
> > the program. However, `nvram_status' is not `volatile', so we need
> > not consider that potential complication.
>
> --
> Mark

I tried the same program i got -1 as output for all try. i have seen
no weird behavior.

nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1
nvram_init : nvram_status=-1

Mark you can give some more information like compiler and may be
optimization that you are trying So that some people can better
analyze the problem

== 5 of 6 ==
Date: Mon, Dec 27 2010 8:13 pm
From: "Mark"

Eric Sosman wrote:
> It seems you like to dispense information drop by precious drop,
> one tiny tidbit at a time. If the information is so very private that
> you dare not share it except in meaningless driblets -- well, I have
> never been known as a patient man, and I think I've got better things
> to do than spend time wheedling details from a coy Twenty Questions
> player.

:-)
Appreciate your delightful sense of humour, it indeed cheered me up. The
information isn't private at all, at first I thought the function is pretty
lengthy to be posted here, therefore I provided just a snippet as you asked.
I've posted the source of the routine under question at
http://clc.pastebin.com/f4FRqgit

--
Mark

== 6 of 6 ==
Date: Tues, Dec 28 2010 12:46 am
From: Ike Naar

On 2010-12-28, Mark <mark_cruzNOTFORSPAM@hotmail.com> wrote:
> I've posted the source of the routine under question at
> http://clc.pastebin.com/f4FRqgit

Unfortunately that code is uncompilable. It needs types (e.g. si_t)
that you haven't provided. Also, you don't show how the nvram_init
function is called from its environment.
Given the behaviour that you're seeing, it's not unlikely that there
is an error elsewhere in your program (outside the nvram_init function).
Please provide a minimal, but complete program that exhibits the
problematic behaviour, that we can compile and run.

==============================================================================
TOPIC: How to check whether malloc has allocated memory properly in case if
malloc(0) can return valid pointer
http://groups.google.com/group/comp.lang.c/t/b637a7ebdebcf3b1?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Dec 27 2010 7:24 pm
From: nospam@see.signature (Richard Maine)

Uno <merrilljensen@q.com> wrote:

> It was my understanding that before 1966, IBM was "standard fortran."

No. It was just IBM's Fortran, generally with the particular compiler
version number. The term "standard" was neither applicable nor generally
used.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

== 2 of 2 ==
Date: Mon, Dec 27 2010 9:31 pm
From: Malcolm McLean

On Dec 20, 8:28 pm, David Resnick <lndresn...@gmail.com> wrote:
>
> A reasonable solution for this is to wrap malloc. That lets you
> define a behavior rather than depending on the implementations one.
> e.g. if you get my_malloc(0) you could return NULL directly, or return
> malloc(1). And if central handling of malloc failures is appropriate
> to your program (e.g. abort on malloc() return of NULL), this wrapper
> for malloc gives you a place to handle that as well.
>
You can easily write mymalloc.c. The problem is that your leaf
routines become dependent on it, and therefore no longer leaf
routines. So you can't move them to another program, and they can't be
corrected by someone who isn't an expert in your particular program.

==============================================================================
TOPIC: EXTORADINARY HOT PHOTOS
http://groups.google.com/group/comp.lang.c/t/06514e452847f477?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 27 2010 8:28 pm
From: guru datta

==============================================================================
TOPIC: Binary Search in C
http://groups.google.com/group/comp.lang.c/t/dac735d08655358b?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Dec 27 2010 8:57 pm
From: arnuld

> On Mon, 27 Dec 2010 10:26:53 -0800, Barry Schwarz wrote:

>> On 27 Dec 2010 12:07:49 GMT, arnuld <sunrise@invalid.address> wrote:
>> if(2 != argc)
>> {
>> fprintf(stderr,"USAGE: ./exec [character]\n");

> Brackets are usually used to indicate optional parameters.

Okay, understood.

>> exit(EXIT_FAILURE);
>> }
>> else

> When the if portion of a simple if-else construct ends with a statement
> that jumps out of the normal sequence (e.g., return, break, call to a
> function that does not return such as exit and abort), the else is
> superfluous. Removing the else and the two braces would result in the
> exact same execution sequence of statements.

Understood this as well.

> While size_t is definitely an unsigned integer, it need not be an
> unsigned int. You should cast the expressions if you don't want to use
> on the new C99 formats.

casting a bigger type to smaller type, e.g. from long to int or even
unsigned int to int, may cause strange results if value can't fit in the
type being assigned too. Therefore I have to check for range errors,
something like:

if((ERANGE == errno && (INT_MAX == num || INT_MIN == num)) ||
(0 != errno && 0 == num))

Then 50% of the code will be there for error checking (mostly 60% of my
code is error-checking one). Is this the recommended way ?

--
http://www.lispmachine.wordpress.com

== 2 of 2 ==
Date: Mon, Dec 27 2010 10:48 pm
From: Barry Schwarz

On 28 Dec 2010 04:57:21 GMT, arnuld <sunrise@invalid.address> wrote:

>> On Mon, 27 Dec 2010 10:26:53 -0800, Barry Schwarz wrote:
>

snip

>> While size_t is definitely an unsigned integer, it need not be an
>> unsigned int. You should cast the expressions if you don't want to use
>> on the new C99 formats.
>
>casting a bigger type to smaller type, e.g. from long to int or even
>unsigned int to int, may cause strange results if value can't fit in the
>type being assigned too. Therefore I have to check for range errors,
>something like:
>
> if((ERANGE == errno && (INT_MAX == num || INT_MIN == num)) ||
> (0 != errno && 0 == num))
>
>
>Then 50% of the code will be there for error checking (mostly 60% of my
>code is error-checking one). Is this the recommended way ?

Only if you want to play dumb.

What part of your code do you think will set errno? Why are you
testing unsigned values against INT_MIN?

All your values are less than 100 so casting them to an int would not
overflow. In any event, you were using %u so you should cast them to
unsigned int which cannot overflow (though it can produce unexpected
results).

If you really have to worry about an array in excess of 65536 bytes,
then cast the value to unsigned long and use %lu as your format. This
will support arrays up to 4GB. Just don't post your initialization
definition here when you have one that big.

--
Remove del for email

==============================================================================
TOPIC: Getting a runtime error::"The instruction at 0x004010b4 referenced
memory at 0x00000000. The memory could not be read
http://groups.google.com/group/comp.lang.c/t/e42df39e73323505?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Dec 27 2010 10:48 pm
From: Barry Schwarz

On 28 Dec 2010 00:17:13 GMT, jt@toerring.de (Jens Thoms Toerring)
wrote:

>Jens Thoms Toerring <jt@toerring.de> wrote:
>I didn't treat the case that there are 255 or more of the same
>bytes in a row correctly, so two corrections must be made:
>
>> static void
>> rle_encode( void )
>> {
>> unsigned char count = 1,
>> curr,
>> next = 0;
>> int res;
>>
>> /* Get the very first byte from the file */
>>
>> res = get_a_byte( &curr );
>>
>> /* Keep going while something could be read in */
>>
>> while ( res != 0 )
>> {
>> /* Get a new byte from the file - stop if we already read 255 bytes
>> of the same value, if nothing could be read anymore or if the new
>> bytes value differs from the old one */
>
>> while ( count < 255 && ( res = get_a_byte( &next ) ) && next == curr )
>> count++;

This no longer computes the letter distribution but counts consecutive
letters. Maybe you should first decide what the intent is.

>>
>> /* Store the count and the value */
>>
>
>Insert here
>
> if ( count > 0 )
>> output_rle_data( count, curr );
>>
>> /* Prepare for the next round with the byte we've just read in */
>>
>> curr = next;
>> count = 1;
>
>Make that instead
>
> count = count == 255 ? 0 : 1
>
>> }
>> }
> Regards, Jens

--
Remove del for email

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, December 28, 2010

comp.lang.c - 12 new messages in 5 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts