Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #42767 > unrolled thread

Request for source code review of simple Ising model

Back to article view | Back to comp.lang.c

Contents

  Request for source code review of simple Ising model Udyant Wig <udyant@panda.goosenet.in> - 2014-04-10 23:38 +0530
    Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-10 13:30 -0700
      Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-12 00:34 +0530
        Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-11 12:25 -0700
        Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-16 01:12 +0530
          Re: Request for source code review of simple Ising model Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-16 01:33 +0100
            Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-16 17:57 +0530
              Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-16 06:00 -0700
              Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-16 10:58 -0400
                Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-16 09:07 -0700
                  Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-16 12:22 -0400
                    Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-16 10:38 -0700
                      Re: Request for source code review of simple Ising model Kaz Kylheku <kaz@kylheku.com> - 2014-04-16 19:37 +0000
                  Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-17 12:00 +0530
                    Re: Request for source code review of simple Ising model glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-17 09:32 +0000
                      Re: Request for source code review of simple Ising model "BartC" <bc@freeuk.com> - 2014-04-17 12:24 +0100
                        Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-17 08:16 -0700
                      Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-17 04:41 -0700
                        Re: Request for source code review of simple Ising model Les Cargill <lcargill99@comcast.com> - 2014-04-17 07:49 -0500
                    Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-17 08:00 -0700
                      Re: Request for source code review of simple Ising model Kaz Kylheku <kaz@kylheku.com> - 2014-04-17 15:06 +0000
                        Re: Request for source code review of simple Ising model Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-18 21:04 -0700
                      Re: Request for source code review of simple Ising model glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-17 18:38 +0000
                        Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-17 15:26 -0400
                          Re: Request for source code review of simple Ising model "BartC" <bc@freeuk.com> - 2014-04-17 21:00 +0100
                            Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-17 16:34 -0400
                            Re: Request for source code review of simple Ising model glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-18 04:31 +0000
                        Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-17 14:05 -0700
                          Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-17 17:06 -0700
                          Re: Request for source code review of simple Ising model glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-18 04:54 +0000
                          Re: Request for source code review of simple Ising model Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-18 11:51 -0700
                Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-17 11:42 +0530
              Re: Request for source code review of simple Ising model Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-16 16:54 +0100
                Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-16 15:22 -0700
                Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-17 13:03 +0530
                  Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-17 08:44 -0700
                    Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-17 12:12 -0400
                      Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-18 12:38 +0530
                      Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-18 03:11 -0700
                    Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-18 12:32 +0530
                      Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-18 10:05 -0400
          Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-16 07:10 +0000
          Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-17 13:10 -0400
            Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-18 18:24 +0530
              Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-18 09:52 -0400
                Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-18 20:04 +0530
                  Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-18 11:00 -0400
                    Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-20 01:49 +0530
                      Re: Request for source code review of simple Ising model glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-19 21:20 +0000
                        Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-20 11:11 +0530
                          Re: Request for source code review of simple Ising model Richard Damon <Richard@Damon-Family.org> - 2014-04-20 09:06 -0400
                        Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-20 10:50 -0400
                          Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-21 09:14 -0700
                Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-19 05:43 +0000
              Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-18 19:47 +0530
              Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-21 01:21 +0530
                Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-20 14:24 -0700
                  Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-21 10:40 +0530
                Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-21 12:29 +0530
            Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-18 08:36 -0700
              Re: Request for source code review of simple Ising model James Kuyper <jameskuyper@verizon.net> - 2014-04-18 13:40 -0400
                Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-18 11:14 -0700
                Re: Request for source code review of simple Ising model Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-18 13:55 -0700
              Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-19 01:25 +0530
                Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-19 01:44 +0530
                Re: Request for source code review of simple Ising model Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 20:24 +0000
                Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-18 13:36 -0700
                  Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-19 20:18 +0530
                Re: Request for source code review of simple Ising model Richard <rgrdev_@gmail.com> - 2014-04-19 14:55 +0100
                  Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-20 02:10 +0530
              Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-19 05:40 +0000
                Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-19 14:39 -0700
                  Re: Request for source code review of simple Ising model Ian Collins <ian-news@hotmail.com> - 2014-04-20 10:44 +1200
                    Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-19 17:11 -0700
                    Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-20 11:24 +0530
                  Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-19 17:19 -0700
                    Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-20 10:10 +0000
                      Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-20 14:21 -0700
                        Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-20 22:18 +0000
                          Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-20 19:27 -0700
                            Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-21 12:38 +0000
                            Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-21 18:12 +0530
                            Re: Request for source code review of simple Ising model Ike Naar <ike@iceland.freeshell.org> - 2014-04-21 13:13 +0000
                              Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-21 19:46 +0530
                              Re: Request for source code review of simple Ising model Keith Thompson <kst-u@mib.org> - 2014-04-21 09:06 -0700
                  Re: Request for source code review of simple Ising model jacob navia <jacob@spamsink.net> - 2014-04-21 00:26 +0200
          Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-18 01:15 +0530
          Re: Request for source code review of simple Ising model Udyant Wig <udyantw@gmail.com> - 2014-04-20 11:46 +0530

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#43041

On 2014-04-17, Keith Thompson <kst-u@mib.org> wrote:
> Udyant Wig <udyantw@gmail.com> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>> | If you don't mind making your code a bit non-portable (and in fact
>> | systems where 0.0 and NULL *aren't* represented as all-bits-zero are
>> | rare), then calloc() or memset() can be reasonable.  It will at least
>> | make the initial contents of the allocated memory consistent, even if
>> | it's not necessarily correct.
>>
>>  As I did not use floats or doubles, I suppose the program is safe.
>
> It should be (at least as far as that's concerned).  The standard
> guarantees that all-bits-zero is a representation of 0 for any
> integer type.
>
> (Interestingly, this was not guaranteed by the C90 or C99 standard.
> It was added to one of the C99 Technical Corrigenda, presumably
> because *all* implementations already work that way.)

Yes, it is required in C90.

C90 requires a pure binary representation for unsigned integers, and one of
three choices for signed integers: two's complement, one's complement or
sign-magnitude for signed ones. All these representations have an all bits
zero.

[toc] | [prev] | [next] | [standalone]

#43112

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2014-04-17, Keith Thompson <kst-u@mib.org> wrote:
>> Udyant Wig <udyantw@gmail.com> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>> [...]
>>> | If you don't mind making your code a bit non-portable (and in
>>> | fact systems where 0.0 and NULL *aren't* represented as
>>> | all-bits-zero are rare), then calloc() or memset() can be
>>> | reasonable.  It will at least make the initial contents of the
>>> | allocated memory consistent, even if it's not necessarily
>>> | correct.
>>>
>>>  As I did not use floats or doubles, I suppose the program is
>>>  safe.
>>
>> It should be (at least as far as that's concerned).  The standard
>> guarantees that all-bits-zero is a representation of 0 for any
>> integer type.
>>
>> (Interestingly, this was not guaranteed by the C90 or C99 standard.
>> It was added to one of the C99 Technical Corrigenda, presumably
>> because *all* implementations already work that way.)
>
> Yes, it is required in C90.
>
> C90 requires a pure binary representation for unsigned integers,
> and one of three choices for signed integers:  two's complement,
> one's complement or sign-magnitude for signed ones.  All these
> representations have an all bits zero.

Apparently you misunderstood or are misremembering.  C90 does not
mention one's complement or sign-magnitude, and mentions two's
complement only in footnotes and examples, not in normative text.
The only types[*] required to have all bits of the representation
participate in the value are the character types, and all other
integral types may have what are now called padding bits, in both
C90 and C99.  There are no requirements placed on what sets of
values of any padding bits correspond to numeric values in C90 or
the original version of C99;  in C90 they are not mentioned, in
C99 explicitly unspecified.  The wording used in C90 can be read
different ways, but this aspect was addressed and resolved quite
clearly in the official response of Defect Report 069.  So the
requirement that an object representation of all zero bits must
be a valid representation of an integer-type zero was not
expressed in the Standard until N1256.

[*] In C99 there also are some optional integer types where all
bits of the representation must participate in the value.  Also
I think IEEE-compliant floating point values have the property
that all bits of the representation participate in the value,
but again this is optional, not required of all implementations.

[toc] | [prev] | [next] | [standalone]

#43048

Keith Thompson <kst-u@mib.org> wrote:

(snip)
> It should be (at least as far as that's concerned).  The standard
> guarantees that all-bits-zero is a representation of 0 for any
> integer type.
 
> (Interestingly, this was not guaranteed by the C90 or C99 standard.
> It was added to one of the C99 Technical Corrigenda, presumably
> because *all* implementations already work that way.)

Can you give an example of what C90 allowed?

My interpetation of C90 was that it allowed for sign magnitude,
ones complement, and twos complement.  (Of the ones that actually
made any sense.)

As well as I knew it, K&R allowed for more than that.

-- glen

[toc] | [prev] | [next] | [standalone]

#43049

On 04/17/2014 02:38 PM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
> 
> (snip)
>> It should be (at least as far as that's concerned).  The standard
>> guarantees that all-bits-zero is a representation of 0 for any
>> integer type.
>  
>> (Interestingly, this was not guaranteed by the C90 or C99 standard.
>> It was added to one of the C99 Technical Corrigenda, presumably
>> because *all* implementations already work that way.)
> 
> Can you give an example of what C90 allowed?

I don't have a copy of C90, so I can't be sure. I do know that a
definition for "trap representation", and wording that made use of that
term, were added in C99. That addition was bitterly debated - it was
felt by many that the wording of C90 already clearly allowed for trap
representations, without explicitly needing to name them as such; I
think there was even a DR whose resolution said so, possibly implicitly.
Personally, I think it's convenient to have a name for them, and
explicit mention of their significance, even if it is in fact
technically redundant.

I believe that one possibility allowed by C90 was an integer type with
one or more padding bits. Such a padding bit could be either a mark
parity bit, or an odd parity bit - either of those options would
prohibit 0 from being represented by all-bits-zero.

[toc] | [prev] | [next] | [standalone]

#43051

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:53502AD2.2050506@verizon.net...

> I believe that one possibility allowed by C90 was an integer type with
> one or more padding bits. Such a padding bit could be either a mark
> parity bit, or an odd parity bit - either of those options would
> prohibit 0 from being represented by all-bits-zero.

These are parity bits accessible from software? The ones I've come across 
were dealt with in hardware and wouldn't impact on using all-bits-zero for 
any values. They would in fact be completely transparent.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#43052

On 04/17/2014 04:00 PM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:53502AD2.2050506@verizon.net...
> 
>> I believe that one possibility allowed by C90 was an integer type with
>> one or more padding bits. Such a padding bit could be either a mark
>> parity bit, or an odd parity bit - either of those options would
>> prohibit 0 from being represented by all-bits-zero.
> 
> These are parity bits accessible from software? The ones I've come across 
> were dealt with in hardware and wouldn't impact on using all-bits-zero for 
> any values. They would in fact be completely transparent.

Completely transparent bits don't count as padding bits for the purposes
of the C standard. Padding bits can always be made visible by accessing
the memory as if it were an array of unsigned char. The fact that those
bits are padding bits means that they would be invisible (unless they
give the object a trap representation) when viewing that same memory
using an lvalue of the integer type for which they constitute padding
bits. It would be up to the implementation to make sure a) that the
padding bits are actually invisible and b) that they get set to valid
values when code with defined behavior is used to write the values to
memory.

Please do NOT ask me to provide real-world examples. I'm just trying to
give an example of something that was allowed by C90, but not by C99.
I'm fairly certain that the committee would not have changed the
standard to disallow such an implementation, if they had been aware of
any significant number of real-world implementations where something
like that was actually being done. If nobody was doing anything like
that, there's probably no good motivation for doing anything like that -
so for the same reason, please don't ask me to provide such a motivation.

[toc] | [prev] | [next] | [standalone]

#43055

BartC <bc@freeuk.com> wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:53502AD2.2050506@verizon.net...
 
>> I believe that one possibility allowed by C90 was an integer type with
>> one or more padding bits. Such a padding bit could be either a mark
>> parity bit, or an odd parity bit - either of those options would
>> prohibit 0 from being represented by all-bits-zero.
 
> These are parity bits accessible from software? The ones I've come across 
> were dealt with in hardware and wouldn't impact on using all-bits-zero for 
> any values. They would in fact be completely transparent.

There might have been processors where parity bits weren't 
completely transparent. There are stories of WATFOR on the 7090
using parity to detect undefined variables. It would set the wrong
parity on all memory at the beginning, and trap access with parity 
errors.

With ECC, it is also not completely transparent. If you write smaller
than the ECC word size, where 64 bits isn't unusual, the memory 
system has to fetch (check and correct) the whole word, change
the byte or bytes needed, then write back the new value with new
ECC bits. At power up, the ECC bits are usually not right, so 
someone (usually the OS) has to write with the appropriate 
instruction some value (usually zero) through all of memory.

(ECC on 64 bits is convenient, as it takes 8 ECC bits, the same
as needed for byte parity.)

-- glen

[toc] | [prev] | [next] | [standalone]

#43053

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
> (snip)
>> It should be (at least as far as that's concerned).  The standard
>> guarantees that all-bits-zero is a representation of 0 for any
>> integer type.
>  
>> (Interestingly, this was not guaranteed by the C90 or C99 standard.
>> It was added to one of the C99 Technical Corrigenda, presumably
>> because *all* implementations already work that way.)
>
> Can you give an example of what C90 allowed?
>
> My interpetation of C90 was that it allowed for sign magnitude,
> ones complement, and twos complement.  (Of the ones that actually
> made any sense.)
>
> As well as I knew it, K&R allowed for more than that.

C90 did not say much about the representation of signed integer types.
It says:

    The representations of integral types shall define values by use of
    a pure binary numeration system.

There's no mention of 2's-complement or any other signed
representation scheme.  But it did require any value representable
both as a signed int and as an unsigned int to have the same
representation in both (likewise for other signed/unsigned paris),
which eliminates some possible schemes.

C99 limited the scope of that statement:

    Values stored in unsigned bit-fields and objects of type unsigned
    char shall be represented using a pure binary notation.

It introduced the distinction between value bits and padding bits (which
C90 didn't mention) and required signed integer types to be represented
using either sign and magnitude, two's complement, or one's complement.

I *think* that C90 implicitly permitted padding bits, even though it
didn't mention them.  One could argue that the phrase "pure binary
numeration system" is inconsistent with padding bits, but C99 does use
the phrase "pure binary representation" in reference to just the value
bits.  And it would be odd for C99 to loosen the requirements for integer
representation relative to C90 while simultaneously tightening the
requirements for signed representation by listing the three permitted
forms.

So assuming that C90 permitted padding bits, you could imagine an
implementation where int is 32 bits, but one of the bits is a padding
bit that must be set to 1.  I'm fairly sure such an implementation is
permitted (perhaps unintentionally) by the original C99 standard.  It's
specifically forbidden the second Technical Corrigendum, and therefore
by N1256 and C11.

The change was introduced in response to Defect Report #263 and
published in TC 2.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43054

Keith Thompson <kst-u@mib.org> writes:
[...] 
> I *think* that C90 implicitly permitted padding bits, even though it
> didn't mention them.  One could argue that the phrase "pure binary
> numeration system" is inconsistent with padding bits, but C99 does use
> the phrase "pure binary representation" in reference to just the value
> bits.  And it would be odd for C99 to loosen the requirements for integer
> representation relative to C90 while simultaneously tightening the
> requirements for signed representation by listing the three permitted
> forms.
[...]

And I realized that a standard could permit padding bits but not permit
trap representations.  I believe that C90 implicitly permitted both
padding bits and trap representations (basically because it didn't
forbid them).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43056

Keith Thompson <kst-u@mib.org> wrote:

(snip, I wrote)

>> Can you give an example of what C90 allowed?

>> My interpetation of C90 was that it allowed for sign magnitude,
>> ones complement, and twos complement.  (Of the ones that actually
>> made any sense.)

>> As well as I knew it, K&R allowed for more than that.
 
> C90 did not say much about the representation of signed integer types.
> It says:
 
>    The representations of integral types shall define values by use of
>    a pure binary numeration system.
 
> There's no mention of 2's-complement or any other signed
> representation scheme.  But it did require any value representable
> both as a signed int and as an unsigned int to have the same
> representation in both (likewise for other signed/unsigned paris),
> which eliminates some possible schemes.

Not counting padding bits, and using the same number of bits for
signed and unsigned, three choices that work and make sense are
sign magnitude, ones, and twos, complement.

You could imagine a system where the value bits had the same position
(except the sign bit) as unsigned when the sign bit was zero, and
completely different positions when it was one, but that doesn't
make much sense. It also disallows a biased representation
(twos complement with the sign bit inverted). 

Seems to me that there could be hardware without an unsigned
representation (or the ability to do arithmetic on one), such
that C unsigned types had half the range of C signed types.
(That is, INT_MAX equals UINT_MAX.)  (For twos complement, you
can fake unsigned with some extra work. Much harder with ones
complement.) For hardware with a biased represenation, you
could call the sign bit a padding bit, which should be 1 for
unsigned types.

I believe, though, that the "all bits zero for zero" idea is so
deep in the minds of hardware designers that it isn't likely
to happen.

> C99 limited the scope of that statement:
 
>    Values stored in unsigned bit-fields and objects of type unsigned
>    char shall be represented using a pure binary notation.
 
> It introduced the distinction between value bits and padding bits (which
> C90 didn't mention) and required signed integer types to be represented
> using either sign and magnitude, two's complement, or one's complement.

I am still waiting for a C compiler for the 7090 to try out
sign magnitude. As far as I know, the last (well, maybe the 7094)
of the sign magnitude machines.
 
> I *think* that C90 implicitly permitted padding bits, even though it
> didn't mention them.  One could argue that the phrase "pure binary
> numeration system" is inconsistent with padding bits, but C99 does use
> the phrase "pure binary representation" in reference to just the value
> bits.  And it would be odd for C99 to loosen the requirements for integer
> representation relative to C90 while simultaneously tightening the
> requirements for signed representation by listing the three permitted
> forms.
 
> So assuming that C90 permitted padding bits, you could imagine an
> implementation where int is 32 bits, but one of the bits is a padding
> bit that must be set to 1.  I'm fairly sure such an implementation is
> permitted (perhaps unintentionally) by the original C99 standard.  It's
> specifically forbidden the second Technical Corrigendum, and therefore
> by N1256 and C11.
 
> The change was introduced in response to Defect Report #263 and
> published in TC 2.
 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_263.htm

-- glen

[toc] | [prev] | [next] | [standalone]

#43090

Keith Thompson <kst-u@mib.org> writes:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> wrote:
>> (snip)
>>> It should be (at least as far as that's concerned).  The standard
>>> guarantees that all-bits-zero is a representation of 0 for any
>>> integer type.
>>  
>>> (Interestingly, this was not guaranteed by the C90 or C99
>>> standard.  It was added to one of the C99 Technical Corrigenda,
>>> presumably because *all* implementations already work that way.)
>>
>> Can you give an example of what C90 allowed?
>>
>> My interpetation of C90 was that it allowed for sign magnitude,
>> ones complement, and twos complement.  (Of the ones that actually
>> made any sense.)
>>
>> As well as I knew it, K&R allowed for more than that.
>
> C90 did not say much about the representation of signed integer
> types.  It says:
>
>     The representations of integral types shall define values by
>     use of a pure binary numeration system.

Note:  "representations ... shall define values by ...".  I take
this statement to concern only those bits in the representation that
define the value, not necessarily all bits in the representation.

> There's no mention of 2's-complement or any other signed
> representation scheme.  But it did require any value representable
> both as a signed int and as an unsigned int to have the same
> representation in both (likewise for other signed/unsigned paris),
> which eliminates some possible schemes.
>
> C99 limited the scope of that statement:
>
>     Values stored in unsigned bit-fields and objects of type
>     unsigned char shall be represented using a pure binary
>     notation.

I read these two statements as saying rather different things, with
neither being a subset of the other.  The provision in C89/C90 I
read as giving a constraint on those bits that define the value of
the corresponding type, but not on other bits (ie, what we now call
"value bits").  The provision in C99 I read as giving a constraint
on /all/ bits in the object representation of the corresponding type
(ie, that value bits make up all bits of the representation).
Thus the C99 statement is a stronger condition, but applies less
generally - it requires more, but only in the two cases listed.

> It introduced the distinction between value bits and padding bits
> (which C90 didn't mention) and required signed integer types to be
> represented using either sign and magnitude, two's complement, or
> one's complement.
>
> I *think* that C90 implicitly permitted padding bits, even though it
> didn't mention them.  One could argue that the phrase "pure binary
> numeration system" is inconsistent with padding bits, but C99 does
> use the phrase "pure binary representation" in reference to just the
> value bits.  And it would be odd for C99 to loosen the requirements
> for integer representation relative to C90 while simultaneously
> tightening the requirements for signed representation by listing the
> three permitted forms.

Focusing on the "pure binary ..." phrase is a misdirection.  In all
cases it refers to all the bits under consideration, but which bits
those are is determined by context outside the phrase itself.  In
some cases that is just the value bits, in others all bits in the
object representation.

In any case, the question of whether C89/C90 allows padding bits, or
trap representations, in integral types is addressed in Defect
Report #069, dated December 3, 1993.  The short answer is that it
allows both, not counting some exceptions in the case of character
types.  Since I have the page open here is the link:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_069.html

[toc] | [prev] | [next] | [standalone]

#43033

James Kuyper <jameskuyper@verizon.net> writes:
| calloc() is functionally equivalent to malloc() followed by memset().
| There's no plausible reasons why calloc() would ever be significantly
| slower than malloc()+memset(). However, on some systems, dynamically
| allocated memory is automatically zeroed out, whether allocated by
| calloc() or malloc() - on such systems, malloc()+memset() would be a
| waste of time, so you should simply call calloc().

 I tried both malloc() + memset() and calloc().  I did not notice much
 of a difference in running time.
 
| You are. main() doesn't do anything between calling allocate_lattice()
| and initialize_lattice(). allocate_lattice() does nothing to
| initialize the lattice (which make sense). initialize_lattice()
| doesn't do anything before reaching the following line, to initialize
| *cell:
|
|     *cell &= ~0x02;
|
| Since that line is equivalent to
|
|     *cell = *cell & ~0x02;
|
| the second *cell reads the uninitialized memory allocated by
| allocate_lattice().

 Oh dear.  A moment's oversight that did not yield dire results,
 thankfully.

 The lattice has since been zeroed after allocation via memset().
 
| As a general rule, you should avoid globals - they make it harder to
| keep track of which function is responsible for each change to the
| global. I'd create the pointer at block scope in main(), and pass it
| to all of the functions that need access for it. In a small program,
| it doesn't make much difference. However, in a larger program passing
| around the pointer explicitly makes it much easier to track down which
| function is responsible for something happening.

 After scrutinizing the source, it turns out that I did not need the
 lattice to be global at all.  It is now declared in main() with no ill
 effect.

| There's another advantage: if at some future time you want to create a
| modified version of your program that involves running two different
| Ising models at the same time, with different parameters, in order to
| compare the results, using pointers makes that easy. Using globals
| would not.

 Ah.  Another feature I did not think of.

[toc] | [prev] | [next] | [standalone]

#43016

Udyant Wig <udyantw@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
> | There are a few things I find stylistically odd, but there is a more
> | significant issue that you should address: malloc does not initialise
> | the data it allocates.  Since your "initialize_lattice" function just
> | sets the cells based on their current content, at no time is the data
> | made determinate.  Obviously, you usually get zeros (your system may
> | even guarantee you get zeros) but C does not guarantee this.
>
>  Should I have used calloc() or memset()?

There's no need because you go and set every cell to some initial value.
Calling calloc might have zero extra cost, but it's unnecessary, and
calling memset is just a waste when you subsequently set the cells
yourself.

>  I did run the program through valgrind and it did report errors
>  pertaining to uninitialized memory, but I thought that as I was never
>  actually using or reading from the freshly allocated memory (it was set
>  immediately afterwards in main()), all was well.  I could be
>  mistaken.

You set the cells using |= and &= both of which modify an existing
indeterminate value.  You do end up explicitly setting the second bit
this way, and if you never used any other bits, the code would be
correct*, but since you do use other bits, there is a problem.

It's good that you are using valgrind.  It's a great tool, but you need
to be very sure before deciding that it's mistaken (though it sometimes
is).

*  There's a technicality here that depends on the type used for the
cell and the possibility of trap representations but it's never wise to
use indeterminate data, even if the result happens to be determinate,
and in this case it applies to only one bit in the cell.

> | Stylistically, I'd make more use of function arguments.  I'd make the
> | lattice an argument of the functions that work on it (the one place
> | where you do pass it, you don't make any use of it).
>
>  The only function where I pass it is allocate_lattice(), which takes as
>  actual argument the global lattice pointer, calls malloc(), and returns
>  it.  Should I have done the allocation in main() itself, omitting a
>  separate allocator?

No, my point is that the argument is useless.  The function immediately
overwrites it, so there is no point in passing it at all.  This is
logical -- the allocator does not need to know this pointer unless it is
going to be, one day, a re-allocator used to make new lattices from old
ones.

>  I am still unclear as to the more general situation: given a global
>  pointer, should its allocation be isolated in a function, and if so,
>  what should it return?

I would have, as you have, a separate allocator, and it would return, as
yours does, a pointer to the lattice it has just allocated.  The only
difference is that I'd pass the size as an argument and I would not pass
the value of the lattice pointer, since it's not used.

>  Also, should whichever functions operating on
>  the global take it as an argument or have at it directly?

I'd always use a parameter.  I'd aim to have all functions passed
everything they need to do their job.

> | In several places (two where it might matter for speed) you could do
> | away with the nested loops and the index arithmetic.  Given your data,
> | this pattern:
> |
> |      for (col = 0; col < dimension; col++) {
> |           for (row = 0; row < dimension; row++) {
> |               ... lattice[col * dimension + row]...
> |           }
> |      }
> |
> | can often be replaced with a single loop.  You might even use a pointer:
> |
> |   byte *bp = lattice, *end = bp + dimension * dimension;
> |   while (bp < end) {
> |        ... *bp++ ...
> |   }
> |
> | Of course, the optimiser might do most of this anyway, so there may be
> | no gain at all.
>
>  I replaced every set of nested loops (except the one in
>  print_lattice(); I have yet to figure out the calculations to print a
>  1D array onscreen as 2D) by the pointer loop, and I did see some
>  quickening.  (I seeded the random number generator with an integer for
>  the testing runs.)

Your makefile has -O0 so you may be seeing an improvement in what it bad
generated code to start with.  It maybe that gcc can make your nested
loops as fast as a single one if you give it some rope.

You are right about print_lattice.  Much better to keep the 2D nature of
the lattice clear, but if you want to play, the key steps to doing with
pointers is that bp - lattice is an integer value telling you have far
into the array you are, and (bp - lattice) % dimension tells you where
you are in a row.  There is some fiddling to get the details right, but
do it just for fun -- all this will do is make the function more
obscure.

> | You use a lot of functions (good) but despite having one for each
> | separate command-line error condition (I wouldn't, myself) you've put
> | all the main work into a giant loop in main.
>
>  Indeed.  I have now found that that giant loop can be shipped off into
>  a new function, and said loop in main() can be replaced by a single
>  function call.
>
>  Why would you not have separate functions for command-line error
>  conditions?

I just don't think it pays off in clarity.  You end up with the exit
values spread about, and the message far away from the condition that
triggers it.  I think

  if (something_wrong) {
      fputs("explain what's wrong\n", stderr);
      return 2;
  }

is simpler and clearer than

  if (something_wrong) {
      something_wrong_function();
  }

with 

void something_wrong_function(void)
{
    fputs("explain what's wrong\n", stderr);
    exit(2);
}

being somewhere else in the file.  Also, you've built an obstacle to
printing more helpful errors because anything extra that's needed now has
to passed as a parameter to the error-printing function.
  
> | Finally, a trick the often helps this sort of code is to over allocate
> | the array to leave a border of zero cells.  This means you can eliminate
> | the test for 'col' and 'row' being in bounds and sometimes this pays
> | dividends.
>
>  I tried doing that.  If the desired dimension was to be d, I had it
>  allocate a (d + 2)*(d + 2) lattice.  I also figured out the starting
>  and the ending positions of the actual lattice (which was a sublattice
>  of the one allocated), but I found that the pointer loop I had
>  substituted for nested loops would have to be changed so that the
>  pointer roved only within the sublattice.

Yes, it does not combine well with switching to a 1D loop.

>  Determining whether the benefits of having a zero-border and no
>  boundary-checking four times for each randomly selected cell outweigh
>  the cost of the calculations necessary to rove only in the sublattice
>  is going to take quite a few profiled runs.

Absolutely.  Write for clarity first, and do these alterations only if
it really makes a difference.

>  Thank you for the feedback and commentary.  I am grateful.  I learned
>  much.
>
>  Udyant Wig

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#43032

On Wednesday, April 16, 2014 5:33:14 PM UTC+1, Stefan Ram wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
> >                             I'd aim to have all functions passed
> >everything they need to do their job.
> 
> #include <hypothetical.h>
> 
> int main( STDLIB * stdlib ){ stdlib->puts( "hello, world" ); }
>
Most IO systems are like that.
Typically there's some connection to the GUI which is then passed about,
like the X Display * or the windows HINSTANCE. Even stdlib only has three
global streams.

[toc] | [prev] | [next] | [standalone]

#43035

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>  Should I have used calloc() or memset()?
|
| There's no need because you go and set every cell to some initial
| value.  Calling calloc might have zero extra cost, but it's
| unnecessary, and calling memset is just a waste when you subsequently
| set the cells yourself.

 I have erred on the side of caution in the latest revision and
 explicitly initialized the lattice memory with memset().  At the very
 least, it made Valgrind report no errors.
 
| You set the cells using |= and &= both of which modify an existing
| indeterminate value.  You do end up explicitly setting the second bit
| this way, and if you never used any other bits, the code would be
| correct*, but since you do use other bits, there is a problem.
|
| It's good that you are using valgrind.  It's a great tool, but you
| need to be very sure before deciding that it's mistaken (though it
| sometimes is).
|
| * There's a technicality here that depends on the type used for the
| cell and the possibility of trap representations but it's never wise
| to use indeterminate data, even if the result happens to be
| determinate, and in this case it applies to only one bit in the cell.

 I was doing something very dubious.  I have (hopefully) set things
 right by initializing the memory.
 
| I would have, as you have, a separate allocator, and it would return,
| as yours does, a pointer to the lattice it has just allocated.  The
| only difference is that I'd pass the size as an argument and I would
| not pass the value of the lattice pointer, since it's not used.

 I have done what you suggest:

byte *allocate_lattice (size_t size)
{
    byte *lattice;
    
    errno = 0;
    lattice = malloc (size);
    if (lattice == NULL) {
	fprintf (stderr, "allocate_lattice: %s\n", strerror (errno));
	exit (1);
    }

    memset (lattice, 0, size);
    return lattice;
}

| I'd always use a parameter.  I'd aim to have all functions passed
| everything they need to do their job.

 That makes sense.
 
| Your makefile has -O0 so you may be seeing an improvement in what it
| bad generated code to start with.  It maybe that gcc can make your
| nested loops as fast as a single one if you give it some rope.

 I put -O0 chiefly so that the -g and -pg flags could provide
 information useful to gdb and gprof.
 
| You are right about print_lattice.  Much better to keep the 2D nature
| of the lattice clear, but if you want to play, the key steps to doing
| with pointers is that bp - lattice is an integer value telling you
| have far into the array you are, and (bp - lattice) % dimension tells
| you where you are in a row.  There is some fiddling to get the details
| right, but do it just for fun -- all this will do is make the function
| more obscure.

 I will try doing this as an exercise for later as it looks a touch
 involved.

 As an aside, profiling with gprof shows that print_lattice() takes the
 lion's share of the running time.  A 6x6 lattice ususally finishes
 within half a minute.  A 7x7 lattice takes several minutes to reach its
 final configuration, even if I redirect output to /dev/null.

 I had left a 10x10 lattice running yesterday before dinner (at about
 9:00 in the night) and had forgotten about it.  Some time after
 midnight, when I chanced upon the terminal, it was still running.  I
 did not have the heart to see it continue.
 
| I just don't think it pays off in clarity.  You end up with the exit
| values spread about, and the message far away from the condition that
| triggers it.  I think
|
|   if (something_wrong) {
|       fputs("explain what's wrong\n", stderr);
|       return 2;
|   }
|
| is simpler and clearer than
|
|   if (something_wrong) {
|       something_wrong_function();
|   }
|
| with 
|
| void something_wrong_function(void)
| {
|     fputs("explain what's wrong\n", stderr);
|     exit(2);
| }
|
| being somewhere else in the file.  Also, you've built an obstacle to
| printing more helpful errors because anything extra that's needed now
| has to passed as a parameter to the error-printing function.

 What if the same error-checking code has to be repeated at many places?
 In my case, there are four places in main() where a beta_error()
 occurs.  Should they be replaced by the function body?  What if the
 error message or something else had to be changed or something added?

 One thing that is conceivable is to store all error-related functions
 in separate source file.  But is that a good idea?
 
| Absolutely.  Write for clarity first, and do these alterations only if
| it really makes a difference.

 As the oft-beaten Knuthian horse says: Premature optimization is
 *neigh* root of all evil.

 Well, that was bad.

[toc] | [prev] | [next] | [standalone]

#43043

Udyant Wig <udyantw@gmail.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>  Should I have used calloc() or memset()?
> |
> | There's no need because you go and set every cell to some initial
> | value.  Calling calloc might have zero extra cost, but it's
> | unnecessary, and calling memset is just a waste when you subsequently
> | set the cells yourself.
>
>  I have erred on the side of caution in the latest revision and
>  explicitly initialized the lattice memory with memset().  At the very
>  least, it made Valgrind report no errors.
[...]

Here's a question (I don't know the answer in your case because I
haven't studied your code; perhaps I should).

If you allocate a chunk of memory, it's clear that accessing that
memory before you've stored anything in it is a bug.

If you allocate a chunk of memory and then use memset() to set
it to all zeros (let's assume all-bits-zero represents 0 for all
relevant types), is accessing that memory before you've stored some
meaningful value still a bug?

If a zero value is meaningful, then using memset is probably a good
idea.  For example, zeroing an array of char that's intended to store
a string will give you an empty string.)  But there's a risk that
arbitarily initializing a chunk of memory could just mask errors.
Valgrind, for example, doesn't know what all-bits-zero *means*,
whether it's a meaningful value or just a marker for something you
haven't yet initialized.

If you remove the memset() and Valgrind starts complaining again, it
might be pointing to something that you need to fix.  A bug with
consistent behavior is no better than a bug with random behavior.

Taking a quick look at some of your source code, I see the following
in utilities.c:

    bool is_positive_integer (char *string)
    {
        char *sp;
    
        for (sp = string; *sp != '\0'; sp++) {
        if (!isdigit (*sp)) {
            return false;
            }
        }
    
        return (is_all_zeroes (string) ? false : true);
    }    

isdigit() takes an int argument, not a char, and it requires the
argument to be either within the range of *unsigned* char or EOF;
otherwise its behavior is undefined.  If plain char is signed, you have
undefined behavior if *sp < 0.  You need to write

    isdigit((unsigned char)*sp)

(Yes, it's annoying and counterintuitive, but we're stuck with it.)

This:

    return (is_all_zeroes (string) ? false : true);

is more clearly written as:

    return !is_all_zeroes (string);

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43045

On 04/17/2014 11:44 AM, Keith Thompson wrote:
> Udyant Wig <udyantw@gmail.com> writes:
...
>>  I have erred on the side of caution in the latest revision and
>>  explicitly initialized the lattice memory with memset().  At the very
>>  least, it made Valgrind report no errors.
> [...]
> 
> Here's a question (I don't know the answer in your case because I
> haven't studied your code; perhaps I should).
> 
> If you allocate a chunk of memory, it's clear that accessing that
> memory before you've stored anything in it is a bug.
> 
> If you allocate a chunk of memory and then use memset() to set
> it to all zeros (let's assume all-bits-zero represents 0 for all
> relevant types), is accessing that memory before you've stored some
> meaningful value still a bug?
> 
> If a zero value is meaningful, then using memset is probably a good
> idea.  For example, zeroing an array of char that's intended to store
> a string will give you an empty string.)  But there's a risk that
> arbitarily initializing a chunk of memory could just mask errors.
> Valgrind, for example, doesn't know what all-bits-zero *means*,
> whether it's a meaningful value or just a marker for something you
> haven't yet initialized.

His code initialized the memory as follows:
	    /* Clear second bit */
	    *cell &= ~0x02;
	    /* Set second bit randomly  */
	    *cell |= ((byte) (rand () % 2)) << 1;

Since *cell has the type "unsigned char", it cannot have a trap
representation. Therefore, in the original version of his code, if the
use of uninitialized memory had been intentional (perhaps as some
bizarre substitute for proper randomization?), such code would make
sense. However, since he's corrected the code to memset() the entire
lattice (presumably to 0), this code is overly complicated. The second
bit doesn't need to be cleared, because it's already guaranteed to be
clear. The "|" in the "|=" is unnecessary, because the original value
was already 0. Therefore, those two lines can be simplified to:

          *cell = ((byte) (rand () % 2)) << 1;

And that change, in turn, renders the memset() unnecessary, since the
result no longer depends, in any way, upon the pre-existing value of *cell.

[toc] | [prev] | [next] | [standalone]

#43058

James Kuyper <jameskuyper@verizon.net> writes:
| His code initialized the memory as follows:
| 	    /* Clear second bit */
| 	    *cell &= ~0x02;
| 	    /* Set second bit randomly  */
| 	    *cell |= ((byte) (rand () % 2)) << 1;
|
| Since *cell has the type "unsigned char", it cannot have a trap
| representation. Therefore, in the original version of his code, if the
| use of uninitialized memory had been intentional (perhaps as some
| bizarre substitute for proper randomization?), such code would make
| sense. However, since he's corrected the code to memset() the entire
| lattice (presumably to 0), this code is overly complicated. The second
| bit doesn't need to be cleared, because it's already guaranteed to be
| clear. The "|" in the "|=" is unnecessary, because the original value
| was already 0. Therefore, those two lines can be simplified to:
|
|           *cell = ((byte) (rand () % 2)) << 1;
|
| And that change, in turn, renders the memset() unnecessary, since the
| result no longer depends, in any way, upon the pre-existing value of
| *cell.

 The changes have been made.  The initialization code now does only one
 thing: initialization of the memory allocated by allocate_lattice().

[toc] | [prev] | [next] | [standalone]

#43060

On Thursday, April 17, 2014 5:12:05 PM UTC+1, James Kuyper wrote:
> 
> His code initialized the memory as follows:
> 	    /* Clear second bit */
> 	    *cell &= ~0x02;
> 
> 	    /* Set second bit randomly  */
> 	    *cell |= ((byte) (rand () % 2)) << 1;
> 
Valgrind isn't clever enough t o realise that only one bit is

[toc] | [prev] | [next] | [standalone]

#43057

Keith Thompson <kst-u@mib.org> writes:
| Here's a question (I don't know the answer in your case because I
| haven't studied your code; perhaps I should).
|
| If you allocate a chunk of memory, it's clear that accessing that
| memory before you've stored anything in it is a bug.
|
| If you allocate a chunk of memory and then use memset() to set it to
| all zeros (let's assume all-bits-zero represents 0 for all relevant
| types), is accessing that memory before you've stored some meaningful
| value still a bug?

 It could be considered a bug unless the zeroes in question had meaning.
 
| If a zero value is meaningful, then using memset is probably a good
| idea.  For example, zeroing an array of char that's intended to store
| a string will give you an empty string.)  But there's a risk that
| arbitarily initializing a chunk of memory could just mask errors.
| Valgrind, for example, doesn't know what all-bits-zero *means*,
| whether it's a meaningful value or just a marker for something you
| haven't yet initialized.
|
| If you remove the memset() and Valgrind starts complaining again, it
| might be pointing to something that you need to fix.  A bug with
| consistent behavior is no better than a bug with random behavior.

 Point taken.
 
 James Kuyper pointed out the allocated memory could be set directly,
 obviating the need to access it when it is uninitialized.  This in turn
 would obviate the need for malloc()+memset() or calloc().

 I have made this change.

| Taking a quick look at some of your source code, I see the following
| in utilities.c:
|
|     bool is_positive_integer (char *string)
|     {
|         char *sp;
|     
|         for (sp = string; *sp != '\0'; sp++) {
|         if (!isdigit (*sp)) {
|             return false;
|             }
|         }
|     
|         return (is_all_zeroes (string) ? false : true);
|     }    
|
| isdigit() takes an int argument, not a char, and it requires the
| argument to be either within the range of *unsigned* char or EOF;
| otherwise its behavior is undefined.  If plain char is signed, you have
| undefined behavior if *sp < 0.  You need to write
|
|     isdigit((unsigned char)*sp)
|
| (Yes, it's annoying and counterintuitive, but we're stuck with it.)

 But when might this situation arise?  That is, could there be a string
 some of whose elements were characters < 0?

| This:
|
|     return (is_all_zeroes (string) ? false : true);
|
| is more clearly written as:
|
|     return !is_all_zeroes (string);

 Yes.  That does express the intent more clearly.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web