[META] Talking about talking about C.

[Seebs]

<nit>
And, since the set of "engineers" is a subset of "everyone", the first
statement is still true. &smiley;
</nit>

Heh.

That said, engineers tend to be worse at some specific aspects of
communication, because we tend very much to be used to working in terms
of things where true and false are nicely unambiguous, so we have less
experience with some of the communications skills that are necessary
when a field admits multiple ways of describing what's happening.

-s

 

[Jon]

So, watching the typedef battles, something has become clear to me.

Engineers suck at communicating.

Well you *may* be one then because starting a post with a lame
generalization *is* an f'd-up attempt (were you attempting?) to
communicate.

Underneath it all,

Oh, the proverbial "bottom line". Seebs, that is a *cliche*.

it is perhaps useful to remember that most of the
active participants here are people who have successfully written
reasonably large programs in C, so however they're thinking about C
inside their heads, it *works*.

Ah ha, you motive is "union rep"? Seebs, be it to your dismay, not
everyone who is in this group or visits it is "buying the C spiel". K?

Maybe it's not exactly correct, but
at the bare minimum, you
can be reasonably confident that it's a good enough model to have both
explanatory and predictive power for the behavior of programs on real
machines.

So you are preaching "coding in your father's language" as a *good*
thing?

One of the most useful non-engineering skills I've ever applied to
engineering is learning to communicate better.

Wow, you were actually worse than this before? Rain Man!

Interestingly,
writing clearly, while certainly useful, is by far the lesser part of
this.

More generalization. Age and IQ *do* matter, even though they are
outlawed (how else could a politician attain office without an IQ test?).

The big thing is to learn to listen better.

Who you preaching to? Here's a "cliche": In life, you hear and see more
and more, then you die.

And I still have
a long way to go on that.

Are you drunk? ("for the record").

A friend of mine gave me an excellent summary of a useful tactic

Were you seeking "tactics"?

when
someone who is otherwise apparently pretty rational or well-informed

qualification aside, ...

says something obviously false:
Rather than thinking of it as false, think of it as true, and try
to figure out what it could be true *of*.

You had to *learn* that?

That's certainly contrary to the way engineers usually think!

You don't speak for any other engineer, other than yourself if you are
one or wannabe one.

However, it's very useful.

When did c.l.c become a confessional?

Here's an example of how I might apply that.

I think I have enough info at this juncture about you (not that I need
it).

[snipped what Seebs could not or would not "communicate" concisely, and
the large passage of text delves into technical detail that swamps all he
wrote above]

 

[Jon]

No, everyone sucks at communicating.

**** you, bitch!

 

[Jon]

No, everyone sucks at communicating.

I was just kidding, I couldn't resist. (OK, I'm bad now... I'm still an
angel compared to "y'all", especially that Kite guy).

 

[Jon]

No, everyone sucks at communicating.


Much too absolute.

!!! Don't *respond* to "him", *think* about him.

 

[Jon]

It could be distinct from all of them -- it could be an extended
unsigned integer type.

Seebs, are you an unsigned integer type? ("The Matrix Reknown").

 

[Jon]

You just made that up.

The standard says that size_t is
"the unsigned integer type of the result of the sizeof operator".

Umm, news for you Pete: kmart sucks.

 

[Jon]

I am toying with a notion:

TOO MUCH INFO!!

 

[Jon]

Imagine a compiler which has extended
types which you are NOT allowed to use -- any attempt to declare an
object of these types gets you compiler errors. And which then has
typedef "bless" them, so a typedef name pointing at them can be used.

"Consider that you, may be in, the twilight zone."

 

[Jon]

Sorry... Couldn't help myself.

But she's still pregnant. *You* *were* "the man", now *she* is. < or some
ironous "joke" >

 

[Jon]

Heh.

That said, engineers tend to be worse at some specific aspects of
communication, because we

He said "we" and so "identifies" with "engineers" (we have the beginnings
of a parseable language).

tend very much to be used to working in
terms of things where true and false are nicely unambiguous,

You are so wrong. "engineers" are *not* the "it's black or white"/"yes or
no", they are *not* programmers. Are you afflicted as a programmer?

so we
have less experience with some of the communications skills that are
necessary when a field admits multiple ways of describing what's
happening.

"so"? OK, you are not an engineer but you admire those and wannabe one.
What company to you want to work for? NASA? MS? Do tell.

 

[Jon]

Well said. I probably haven't worked hard enough at this myself in
the typedef thread.

Warriors think in terms of tactics, not engineers. You and Seebs seem to
be both "technicians", and you seem to just want more paycheck for what
you do (or power, or credit?).

 

[Jon]

It varies a lot from person to person. Some people are more likely to
get "trapped" in a bad mental model, just as some people have a harder
time dropping a bad hypothesis than others.

Of course, IQ is outlawed (doesn't count). On the same note, try to buy a
slot machine and put it in your house for use by "your neighbors" to use.
You are free, huh.

 

[Guest]

(Note that the description of the 'z' modifier for fprintf implicitly
assumes that a size_t argument is not promoted, ...)

Excuse me, but I won't note that. The mere fact that the description
of the 'z' modifier doesn't mention that the argument will have been
promoted doesn't count as an assumption that it is not promoted
(regardless of the descriptions of other modifiers).

 

[Joachim Schipper]

(...) t seems that the extended types have to use
identifiers reserved for any use (footnote 28). So it seems to me that
there must exist some name for that type which is not size_t, so
size_t has to be an alias for some type, though there may be no way
for standard code to use that type directly.

A conforming program can use the type name directly. (A strictly
conforming, or even a portable or "clc-compliant" program, cannot.)

I am toying with a notion: Imagine a compiler which has extended types
which you are NOT allowed to use -- any attempt to declare an object of
these types gets you compiler errors. And which then has typedef "bless"
them, so a typedef name pointing at them can be used.

So far as I can tell, "reserved for any use" would permit this kind of
silliness.

As an exercise in perversion, couldn't a C compiler randomly generate a
name (e.g. __SIZE_T_<random_mess>) and typedef size_t to it? This would
require special handling of the appropriate header (<stddef.h>), but
there's no prohibition against that as far as I can tell.

This would, for all practical purposes, render the type inaccessible
even to non-portable programs without requiring any further trickery.

Joachim

 

[Tim Rentsch]

[snip]

An implementor who hated you could in theory use 64 for all the standard
unsigned integer types except unsigned char, and then have the 16-bit
and 32-bit types be extended unsigned integer types.

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....

 

[Ben Bacarisse]

[snip]

An implementor who hated you could in theory use 64 for all the standard
unsigned integer types except unsigned char, and then have the 16-bit
and 32-bit types be extended unsigned integer types.

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.

 

[Tim Rentsch]

[snip]

An implementor who hated you could in theory use 64 for all the standard
unsigned integer types except unsigned char, and then have the 16-bit
and 32-bit types be extended unsigned integer types.

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.
^^^^^^^^^^^^^^^^^^^^^^

 

[Seebs]

As an exercise in perversion,

This clause comes up ENTIRELY too often in comp.lang.c.

couldn't a C compiler randomly generate a
name (e.g. __SIZE_T_<random_mess>) and typedef size_t to it? This would
require special handling of the appropriate header (<stddef.h>), but
there's no prohibition against that as far as I can tell.

Huh, you have a point.

This would, for all practical purposes, render the type inaccessible
even to non-portable programs without requiring any further trickery.

Interesting.

-s

 

[Ben Bacarisse]

[snip]

An implementor who hated you could in theory use 64 for all the standard
unsigned integer types except unsigned char, and then have the 16-bit
and 32-bit types be extended unsigned integer types.

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.
^^^^^^^^^^^^^^^^^^^^^^

No, not exactly. I'd forgotten that assignment does no promotion -- it
just coverts.

Is an implementation conforming if you can't pass a size_t to a function
without a prototype? I think calling

extern void *my_alloc();
long *lp = my_malloc(sizeof *lp);

does what I was trying to do -- the argument is promoted and then
assigned so it is an int that is assigned to the (non-prototype)
size_t parameter (not shown).