Thomas Bushnell writes:
> Actually, the C standard does essentially guarantee two's complement
> arithmetic. It specifies integer overflow behavior and
> signed/unsigned conversion behavior exactly.
It does for unsigned integers, but for signed integers overflow is
undefined behaviour. The clea
Good grief. Can you be more constructive? Do you have a reference
that supports the claim?
On Tue, Jan 15, 2002 at 12:11:35AM -0800, Thomas Bushnell, BSG wrote:
> [EMAIL PROTECTED] writes:
>
> > I don't find any such mention in K&R [1978]. There is nothing I can
> > see to guarantees that MAX_
[EMAIL PROTECTED] writes:
> I don't find any such mention in K&R [1978]. There is nothing I can
> see to guarantees that MAX_INT + 1 < 0.
K&R [1978] is not the C standard.
I don't find any such mention in K&R [1978]. There is nothing I can
see to guarantees that MAX_INT + 1 < 0.
On Tue, Jan 15, 2002 at 12:56:19AM +0100, Torsten Landschoff wrote:
> On Mon, Jan 14, 2002 at 10:03:59AM -0800, Thomas Bushnell, BSG wrote:
> > > I yet have to see a machine that does not u
On Mon, Jan 14, 2002 at 03:51:18PM +0100, David N. Welton wrote:
>
> And what's more, it only indents two at a time. Heretics!
From standards.info:
For the body of the function, our recommended style looks like this:
if (x < foo (y, z))
haha = bar[4] + 5;
else
You want to
On Mon, Jan 14, 2002 at 10:03:59AM -0800, Thomas Bushnell, BSG wrote:
> > I yet have to see a machine that does not use two's complement
> > for integer arithmetic.
>
> Actually, the C standard does essentially guarantee two's complement
> arithmetic. It specifies integer overflow behavior and
>
On Mon, Jan 14, 2002 at 06:01:37PM +0100, Guus Sliepen wrote:
> On Mon, Jan 14, 2002 at 08:58:57AM -0800, [EMAIL PROTECTED] wrote:
>
> > > Why don't you "man fts_read" and implement the correct way of checking
> > > for errors?
> >
> > I believe the author wrote the original loop because the fts_
Torsten Landschoff <[EMAIL PROTECTED]> writes:
> On Sun, Jan 13, 2002 at 10:23:51PM -0800, [EMAIL PROTECTED] wrote:
> > Moreover, the original depends on the fact that (MAX_INT + 1) < 0
> > which, though true, is a guaranteed result. Were I to be running a 64
>
> ... is not a guaranteed ...
>
>
Craig Dickson <[EMAIL PROTECTED]> writes:
> Richard Kettlewell wrote:
>> Even if you don't care about weird platforms, "x > -1" is a
>> ridiculously obscure test in this context; to achieve the same
>> effect it would be much clearer to make x unsigned and do "x <=
>> (unsigned)INT_MAX".
>
> I fi
On Mon, Jan 14, 2002 at 08:58:57AM -0800, [EMAIL PROTECTED] wrote:
> > Why don't you "man fts_read" and implement the correct way of checking
> > for errors?
>
> I believe the author wrote the original loop because the fts_
> functions could fail to operate as expected.
Well please check if the
On Mon, Jan 14, 2002 at 03:36:48PM +0100, Guus Sliepen wrote:
> On Mon, Jan 14, 2002 at 12:04:44AM -0800, [EMAIL PROTECTED] wrote:
>
> [How to write bad code]
>
> Why don't you "man fts_read" and implement the correct way of checking
> for errors?
I believe the author wrote the original loop bec
Richard Kettlewell wrote:
> Even if you don't care about weird platforms, "x > -1" is a
> ridiculously obscure test in this context; to achieve the same effect
> it would be much clearer to make x unsigned and do "x <=
> (unsigned)INT_MAX".
I find "x <= (unsigned) INT_MAX" to be more obscure than
And what's more, it only indents two at a time. Heretics!
--
David N. Welton
Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
Apache Tcl: http://tcl.apache.org/
Personal: http://www.efn.org/~davidw/
On Mon, Jan 14, 2002 at 12:04:44AM -0800, [EMAIL PROTECTED] wrote:
[How to write bad code]
Why don't you "man fts_read" and implement the correct way of checking
for errors?
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[EMAIL PROTECTED]>
pgpuwz8FVAQoR.pgp
Description: PGP si
On Sun, Jan 13, 2002 at 10:23:51PM -0800, [EMAIL PROTECTED] wrote:
> Moreover, the original depends on the fact that (MAX_INT + 1) < 0
> which, though true, is a guaranteed result. Were I to be running a 64
... is not a guaranteed ...
I yet have to see a machine that does not use two's complemen
Reply-To:
In-Reply-To: <[EMAIL PROTECTED]>
On Sun, Jan 13, 2002 at 10:49:09PM -0800, Craig Dickson wrote:
> [EMAIL PROTECTED] wrote:
>
> > On Mon, Jan 14, 2002 at 07:01:17AM +0100, Samuel Tardieu wrote:
> > > On 13/01, [EMAIL PROTECTED] wrote:
> > >
> > > | int i;
> > > | for (i = 0; i > -1
[EMAIL PROTECTED] wrote:
> On Mon, Jan 14, 2002 at 07:01:17AM +0100, Samuel Tardieu wrote:
> > On 13/01, [EMAIL PROTECTED] wrote:
> >
> > | int i;
> > | for (i = 0; i > -1; i += 1) {
> > | // ...
> > | if (terminal_condition)
> > | break;
> > | // ...
> > | }
> > [..
On Mon, Jan 14, 2002 at 07:01:17AM +0100, Samuel Tardieu wrote:
> On 13/01, [EMAIL PROTECTED] wrote:
>
> | int i;
> | for (i = 0; i > -1; i += 1) {
> | // ...
> | if (terminal_condition)
> | break;
> | // ...
> | }
> [...]
> | Moreover, i is never used. The loop co
On Sunday 13 January 2002 10:01 pm, Samuel Tardieu wrote:
> On 13/01, [EMAIL PROTECTED] wrote:
> | int i;
> | for (i = 0; i > -1; i += 1) {
> | // ...
> | if (terminal_condition)
> | break;
> | // ...
> | }
>
> [...]
>
> | Moreover, i is never used. The loop could be reduce
On 13/01, [EMAIL PROTECTED] wrote:
| int i;
| for (i = 0; i > -1; i += 1) {
| // ...
| if (terminal_condition)
| break;
| // ...
| }
[...]
| Moreover, i is never used. The loop could be reduced to
|
| while ((file = fts_read (dir)) != NULL) {
| // ...
| }
Those
20 matches
Mail list logo
