[EMAIL PROTECTED] writes:
I don't find any such mention in KR [1978]. There is nothing I can
see to guarantees that MAX_INT + 1 0.
KR [1978] is not the C standard.
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 KR [1978]. There is nothing I can
see to guarantees that MAX_INT +
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
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
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 reduced to
|
|
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 could be
[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;
| // ...
| }
[...]
| Moreover, i is
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; i += 1) {
|
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 complement
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
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/
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 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 because
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 author's
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 find x = (unsigned)
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 ...
I yet have
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_
functions
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 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
I don't find any such mention in KR [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 use
int i;
for (i = 0; i -1; i += 1) {
// ...
if (terminal_condition)
break;
// ...
}
Let me be more explicit. I'm reading the slocate code to figure out
why it isn't producing a database on my machine. There is a loop that
reads
int i;
// ...
for (i = 0; i -1;
21 matches
Mail list logo
