«

On 27 Okt., 20:04, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Ben Bacarisse <ben.use...@bsb.me.uk> writes:
> > Tim Rentsch <t...@alumni.caltech.edu> writes:
> >> I think you may be missing a much more devious possibility, namely
>
> >> * * #define CHAR_BIT 16
> >> * * typedef _Bool size_t;
>
> >> As far as I can tell an implementation could have this combination
> >> of definitions and still be conforming....
>
> > * size_t sz = sizeof(long);
>
> > will leave sz == 1 if size_t is a synonym for _Bool, and that's surely
> > not permitted.
>
> Have you forgotten 6.3p2?
>
> * * Conversion of an operand value to a compatible type
> * * causes no change to the value or the representation.
> * * * * * *^^^^^^^^^^^^^^^^^^^^^^

6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the
value compares equal to 0; otherwise, the result is 1.

If _Bool values are allowed to be any other than 0 or 1, then 6.3p2
and 6.3.1.2 are contradictory.

Keith Thompson wrote:
> Sorry, "compound statement" was the wrong phrase.
>
> What I really meant was that I tend to pretend that selection and
> iteration statements require braces. For example, I'll write
> if (condition) {
> statement;
> }
> rather than
> if (condition)
> statement;

OK, I suspected that was what you meant indeed.
I tend to do the same, except when the whole selection/iteration
statement fits in one line. (Of course, things are different if I have
to match some external coding convention.)
--
Marcin Grzegorczyk

On 2010-10-28, Trevor <> wrote:
> "Seebs" <usenet-> wrote in message
> news:slrnic6pvs.18ft.usenet-...
>> -- I spend
>> a decade on the ISO C committee.

> What the **** were you *doing*?

You know, I get asked that a lot. It's hard to remember, but as I recall,
most meetings we started out with methamphetamines and expensive hookers,
and by the end of the week we were pretty much doing whatever was left
around.

> Did you consider, at any point, making C any less ****?

From what you've said in your posts here, I sincerely hope we never
did anything that you would have considered "any less ****", though we
did fix up a lot of things that experienced C programmers have usually
regarded as weaknesses or flaws in the language.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

"Trevor" <> writes:
> "Seebs" <usenet-> wrote in message
> news:slrnic6pvs.18ft.usenet-...
>> -- I spend
>> a decade on the ISO C committee.
>
> What the f*** were you *doing*?
>
> Did you consider, at any point, making C any less s***?

[quotation edited for content]

Would you consider offering any kind of *constructive* suggestion?

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"Trevor" <> writes:
> "Keith Thompson" <kst-> wrote in message
> news:...
>> Would you consider offering any kind of *constructive* suggestion?
>
> You can start by giving typedef some teeth, or replacing/augmenting it with
> something stronger.
> As it stands, typedef has about as much force as Hungarian Notation.

Just how easy do you think that would be?

Giving typedef "some teeth", assuming you mean having it actually
create a new type, would break existing code, so that's not an
option.

As for adding a new feature, say "newtype" that's similar to typedef
except that it creates a new type rather than an alias, I wouldn't be
opposed to the idea, but nailing down the semantics wouldn't be easy
(perhaps you missed the recent lengthy thread). Would a "newtype"
for a numeric type be implicitly convertible to other numeric types?
If so, there's not much point (the difference would show up mainly
in the presence of pointers to the new type); if not, that's a
fairly radical change to the semantics of arithmetic expressions.
And you still couldn't use the new feature for existing types in
the standard library (size_t et al) without breaking existing code.

As for struct types, well, we already have the ability to create a
new incompatible types just by declaring a new struct type. Arrays?
Pointers? It's already not clear that typedefing them is a good
idea; a "newtype" feature wouldn't necessarily change that.

In practice, most C programmers manage to use typedefs correctly,
treating them *as if* they were distinct types. I don't claim this
is an ideal situation, but there doesn't seem to be much pressure
to add a new feature to the language.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/29/10 11:47 AM, Keith Thompson wrote:
> "Trevor"<> writes:
>> "Keith Thompson"<kst-> wrote in message
>> news:...
>>> Would you consider offering any kind of *constructive* suggestion?
>>
>> You can start by giving typedef some teeth, or replacing/augmenting it with
>> something stronger.
>> As it stands, typedef has about as much force as Hungarian Notation.
>
> Just how easy do you think that would be?
>
> Giving typedef "some teeth", assuming you mean having it actually
> create a new type, would break existing code, so that's not an
> option.
>
> As for adding a new feature, say "newtype" that's similar to typedef
> except that it creates a new type rather than an alias, I wouldn't be
> opposed to the idea, but nailing down the semantics wouldn't be easy
> (perhaps you missed the recent lengthy thread). Would a "newtype"
> for a numeric type be implicitly convertible to other numeric types?
> If so, there's not much point (the difference would show up mainly
> in the presence of pointers to the new type); if not, that's a
> fairly radical change to the semantics of arithmetic expressions.
> And you still couldn't use the new feature for existing types in
> the standard library (size_t et al) without breaking existing code.

It would turn C into C with objects. We already have that, it's another
language called C++...

--
Ian Collins

Trevor wrote:

> You can start by giving typedef some teeth, or replacing/augmenting it
> with something stronger.
> As it stands, typedef has about as much force as Hungarian Notation.

There isn't a problem with typedef. There is, however, a problem with
people not understanding what it does and believing it is supposed to also
do other stuff or even something else entirely.

If that was the most severe problem regarding C then those who contributed
to the standard should be proud of their work.


Rui Maciel

On 2010-10-29, Rui Maciel <> wrote:
> There isn't a problem with typedef. There is, however, a problem with
> people not understanding what it does and believing it is supposed to also
> do other stuff or even something else entirely.

I'm not sure there is, in that I've yet to see evidence that there's many
people out there who are confused by what it does. I think there's a lot
of confusion about the *terminology*, but not about the reality of what
you can expect a compiler to accept or reject.

The point of treating typedef-names *as if* they were new types is much
like the point of treating a struct pointer *as if* it were an opaque handle.

Sure, you can look inside a FILE *. (Much to my dismay, it turns out that
FILE is "an object type", so it can't be an incomplete type, so you can't
just have it be a pointer to an otherwise unspecified "struct __file" or
something similar; you actually have to complete the type.) But, unless
you're doing something pretty crazy, it's nearly always a bad idea to do
so; instead, you should write your code *as if* you couldn't look inside
it.

Same goes with most other user-created data types. Writing good code means
honoring the *intended* encapsulation and type distinctions, even though
the language, in general, doesn't provide you with the tools to enforce that.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

* Ian Collins <ian->:
> It would turn C into C with objects. We already have that, it's another
> language called C++...

Uhm no, really not. This may be an unpopular thought in a C newsgroup,
but, never mind whether you actually like the ideas of the language or
not, C++ is much more than "C with objects". You can have a minimal
version of "C with objects" just by typedef'ing (jehova!) some
"reference types" (pointers to structs) and a set of functions dealing
with them without revealing their contents to the caller.

Regards,
Felix

--
Felix Palmen (Zirias) + [PGP] Felix Palmen <>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683

On 10/29/10 08:37 PM, Felix Palmen wrote:
> * Ian Collins<ian->:
>> It would turn C into C with objects. We already have that, it's another
>> language called C++...
>
> Uhm no, really not. This may be an unpopular thought in a C newsgroup,
> but, never mind whether you actually like the ideas of the language or
> not, C++ is much more than "C with objects". You can have a minimal
> version of "C with objects" just by typedef'ing (jehova!) some
> "reference types" (pointers to structs) and a set of functions dealing
> with them without revealing their contents to the caller.

If you had kept the context I was replying to, you would see I was
commenting on Keith's (I assume) rhetorical suggestion of adding means
of adding new types with their own conversion rules. Doing so is
trivially easy in C++, but is not something we do in C.

--
Ian Collins