C programming in 2011

[Ralf Damaschke]

On 05/26/2011 04:04 PM, Francois Grieu wrote:
[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();

No, it can't.

Would you please illustrate by an example when that does not
stand?

When j is in range [-8 , 0]

Actually: if(j < -8 || j > 8)
can be rewritten as: if((unsigned)j>8)

Actually not! Consider, say, j = -1. Your first if statement
takes the else-part, your second the then-part - always.

You had had a quarter point when you had argued that the
precision of unsigned might not be larger than that of int.
But:

1: the compiler would know that and not internally rewrite the
expression the way Francis mentioned (for *some* compilers).

2: the vast majority of compilers (if not all, at least all I
know of) have a greater precision for unsigned than for int.

-- Ralf

 

[Branimir Maksimovic]

On 26/05/2011 16:21, Branimir Maksimovic wrote:
On 05/26/2011 04:04 PM, Francois Grieu wrote:
[3] some compilers know that, when j is an int,
if (j<1 || j>8)
foo();
can be rewritten as
if ((unsigned)j-1u>7u)
foo();

No, it can't.

Would you please illustrate by an example when that does not stand?

When j is in range [-8 , 0]

C99 doesn't assure you both are equivalent. I think what Francois
tries to say is that gcc can produce assembly that will do the same as

if ((unsigned)j - 1u > 7u)

and that's indeed what GCC does, since on the architectures GCC
targets with the implementation choices it makes, both are equivalent.

Yes, indeed that is what gcc does .
I simply didn't imagine that casting -1 to unsigned *is not* 1

 

[Branimir Maksimovic]

Branimir Maksimovic wrote:
) On Thu, 26 May 2011 17:23:01 +0200
)
)> On 26/05/2011 16:21, Branimir Maksimovic wrote:
)> > On 05/26/2011 04:04 PM, Francois Grieu wrote:
)> >> [3] some compilers know that, when j is an int,
)> >> if (j<1 || j>8)
)> >> foo();
)> >> can be rewritten as
)> >> if ((unsigned)j-1u>7u)
)> >> foo();
)> >
)> > No, it can't.
)>
)> Would you please illustrate by an example when that does not stand?
)
) When j is in range [-8 , 0]
)
) Actually: if(j < -8 || j > 8)
) can be rewritten as: if((unsigned)j>8)

Is this meant to be some kind of joke ?

No, I didn;t know how casting from signed to unsigned works.

 

[Malcolm McLean]

Pierre Habouzit wrote:

)> On Thu, 26 May 2011 17:23:01 +0200
)>
)>> On 26/05/2011 16:21, Branimir Maksimovic wrote:
)>> > On 05/26/2011 04:04 PM, Francois Grieu wrote:
)>> >> [3] some compilers know that, when j is an int,
)>> >> if (j<1 || j>8)
)>> >>     foo();
)>> >> can be rewritten as
)>> >>     if ((unsigned)j-1u>7u)
)>> >>         foo();
)>> >
)>> > No, it can't.
)>>
)>> Would you please illustrate by an example when that does not stand?
)>
)> When j is in range [-8 , 0]
)
) C99 doesn't assure you both are equivalent.

Are you sure ?  As far as I know, casting a signed integer to unsigned
is defined for negative numbers as being INT_MAX minus that number.

Plus one.
Invert and increment to negate, in twos complememnt

 

[Keith Thompson]

2: the vast majority of compilers (if not all, at least all I
know of) have a greater precision for unsigned than for int.

Depends on what you mean by "precision". For most compilers, signed int
and unsigned int can represent exactly the same number of values.

 

[Ralf Damaschke]

Depends on what you mean by "precision".

Of course I use the term as defined:

C99, 6.2.6.2p6:
| The /precision/ of an integer type is the number of bits it
| uses to represent values, excluding any sign and padding bits.

For most compilers,
signed int and unsigned int can represent exactly the same
number of values.

D'accord, and that's implies that unsigned has a larger precision
than signed.

-- Ralf

 

[Chad]

Oh, what was the name of that server? I'd like to know...



I've been trying to shake the rust off of me for some time, last time I
did any real serious programming was back in college about 10 years ago.


I'm new here myself, joined a few months ago. Seems like a friendly and
helpful group most of the time.

Which reminds me, I should thank everyone who answered my query here.
Making my code more portable didn't only make my program work on Sparc
and PPC, it also made the coding as a whole a heck of a lot easier.

The right wing religious nuts that roam this forum apparently haven't
gotten to you yet.

Chad

 

[Ian Collins]

It's true that very few compilers fully support C99, But it's also true
that compilers which support most of the new features of C99 are quite
commonplace nowadays.

Not to mention those that claim to support it, do.

 

[Keith Thompson]

Of course I use the term as defined:

C99, 6.2.6.2p6:
| The /precision/ of an integer type is the number of bits it
| uses to represent values, excluding any sign and padding bits.


D'accord, and that's implies that unsigned has a larger precision
than signed.

Ah, I forgot that the standard defines the term "precision" for
integer types. (It's possible for signed and unsigned to have the
same precision, but only if unsigned has a padding bit in places
of signed's sign bit, which woudl be unusual.)

Note that the standard also defines the "width" as the "precision"
plus any sign bit.

 

[Keith Thompson]

The right wing religious nuts that roam this forum apparently haven't
gotten to you yet.

What??

 

[James Kuyper]

Plus one.
Invert and increment to negate, in twos complememnt

That's UINT_MAX, not INT_MAX. And it's true whether or not 'int' is a
2's complement type; the rule is simply easier to implement in 2's
complement.

 

[Angel]

The right wing religious nuts that roam this forum apparently haven't
gotten to you yet.

I've been on news.admin.net-abuse.email and alt.religion.scientology.
Trust me, this group is paradise compared to them.

 

[James Kuyper]

On 05/26/2011 05:09 PM, Chad wrote:
....

The right wing religious nuts that roam this forum apparently haven't
gotten to you yet.

Who in the world are you talking about?

 

[Jorgen Grahn]

.

The only oddity I've noticed is indenting in loops, like:

while (foo)
{
bar();
}

That is indeed a Gnu oddity, and probably the default in Emacs.
You should ask it to use one of its other builtin styles or
(in my case) a variation of one of them:

(require 'cc-mode)
(c-add-style "bsd4" '("bsd" (c-basic-offset . 4)))
(setq c-default-style "bsd4")

Let me know when you do ;-) I've figured out just enough to do what I
need, & nothing more

The need to support odd Unixes is smaller today than in 2000.

/Jorgen

 

[Phil Carmody]

Vi IMproved for me, but whatever works. The Linux kernel folks seem not
too fond of emacs' default layout for C though, just saying...

I don't think I've ever see emacs' "linux" style do anything not
approved by the coding standard. Some things aren't specified too
accurately, so emacs may produce different indentation for multi-line
if conditions, for example, but there's no right and wrong in those
few cases.

I guess a straw poll of the half of the kernel team where I worked
would have yielded about 50% emacs-alike, 40% vi-alike, 10% other.
From their patches, I was never able to tell which was which.

Phil

 

[Angel]

I don't think I've ever see emacs' "linux" style do anything not
approved by the coding standard. Some things aren't specified too
accurately, so emacs may produce different indentation for multi-line
if conditions, for example, but there's no right and wrong in those
few cases.

I guess a straw poll of the half of the kernel team where I worked
would have yielded about 50% emacs-alike, 40% vi-alike, 10% other.
From their patches, I was never able to tell which was which.

Coding style is quite a personal thing, and I don't think there is a
real right or wrong in that. It was just something I came across while
browsing through the kernel documentation.

I like putting my accolades on separate lines so I can clearly see
where blocks begin and end, but others like to put their opening
accolade at the end of the if/while/for/function. Like I said earlier,
whatever works for you.

 

[Keith Thompson]

Coding style is quite a personal thing, and I don't think there is a
real right or wrong in that. It was just something I came across while
browsing through the kernel documentation.

I like putting my accolades on separate lines so I can clearly see
where blocks begin and end, but others like to put their opening
accolade at the end of the if/while/for/function. Like I said earlier,
whatever works for you.

Are you sure that "accolade" is the word you're looking for?

 

[Nizumzen]

Good luck.... most compilers do NOT support C99. Those that *claim* to
only support parts of it.

Most areas of the industry tend to avoid C99 all together.

Just ditch GCC for Clang and your life will improve markedly. Plus
Clang's static analyser is awesome.

 

[Angel]

Are you sure that "accolade" is the word you're looking for?

Like I pointed out in another thread, it is the correct word in Dutch.
I'm not a native English speaker.

It does have that meaning in English too, but only in the context of
sheet music, it seems. I think "curly brace" is the correct term, no?

Anyway, I mean these things: {}

 

[Geoff]

Like I pointed out in another thread, it is the correct word in Dutch.
I'm not a native English speaker.

It does have that meaning in English too, but only in the context of
sheet music, it seems. I think "curly brace" is the correct term, no?

Anyway, I mean these things: {}

brackets: []
braces: {}

I thoroughly detest the words curly braces to describe braces.