[META] Talking about talking about C.

I

Ian Collins

and this horror actually comes out of the standard!

It is there as a right of passage. Just as junior doctors are expected
to work 100 hour weeks, junior C programmers are expected to understand
the signal interface.
 
K

Keith Thompson

Scouser said:
Calm down our Kieth!

Thank you, but we heard you the tenth time. I'm quite calm.
And you could at least spell my name right.

You seem to be new here. If you'll read some more of the postings,
you'll find that the useful ones actually discuss something, rather than
quoting an entire article and adding a one-line comment that doesn't
really mean much.
 
N

Nick Keighley

and this horror actually comes out of the standard!


we are where we are. They say every great language has an experiment
that didn't quite work.



I usually pick em apart by hand. And then bung in lots of typedefs so
I never have to do it again!

the other use for tyepdef is to hide the concrete types. I'm not a fan
of heavy use of int32 and so on. But I find Byte or Octet a nice
shorthand for unsigned char. Application specific type aliases can be
useful

typedef double Latitude;

though of course you can still stuff a Weight into a Latitude and get
no squeals from the compiler...

Calm down our Nick!


que?
 
J

Jon

Nick said:
even programmers aren't quite that bad!

"All evidence to the contrary!" e-ehm... hello. Said in *this* room of
"programmers". I "tend" to believe that most vocal here are the "language
lawyer" types, but that's fine if that's what the "group" is, then so be
it. I don't make waves, nor pass judgement. (Most can't/won't admit that
'typedef' sucks as a keyword, though).
"this program works well"
"that function is too big"
"comments like that are a design smell" (though I'm not fond of the
smell metaphor)

I probably miss the "subtlety" in the above, but it's not worth (not my
time anyway) the time to generalize/stereotype/whatever.
I can't see how you read that into what he said

And *I* don't know how you actually grok'd what I said! LOL. For fun,
what do *you* think I "meant"?
 
N

Nick Keighley

I'm not convinced you do
"All evidence to the contrary!"

really? So produce some. Programming teams have to communicate a lot.
Someone has to extract requirements from customers. Programmers get
along in real life.
e-ehm... hello. Said in *this* room of "programmers".

it's not a "room" it's a usenet group.
I "tend" to believe that most vocal here are the "language
lawyer" types, but that's fine if that's what the "group" is, then so be
it. I don't make waves, nor pass judgement. (Most can't/won't admit that
'typedef' sucks as a keyword, though).

it's possible for a rational person to hold an opinion that is not
completly in agreement with yours.
I probably miss the "subtlety" in the above, but it's not worth (not my
time anyway) the time to generalize/stereotype/whatever.

no subtlety present. I was simply illustrating that programmers have
to deal with things that aren't black and white. "too big" is a value
judgment not a defined number of lines with an error bar.
And *I* don't know how you actually grok'd what I said! LOL. For fun,
what do *you* think I "meant"?

you said he "wanted to be" an engineer. Where did he say that? You
implied that he had some sort of thwarted ambition. And wanted to work
for a cool engineering company like NASA or Microsoft. Is NASA still
cool? Was Microsoft ever cool?

My job title is "Software Engineer" so I call myself an engineer on
even days and computer programmer on odd days. No I don't have a
professional engineering qualification.
 
N

Nick Keighley

Heh.

And poor old Nick, trying to emulate his hero "Kieth",  was playing the
bumbling intellectual who doesn't follow things outside of his vt100
based existence.

It is impossible for him NOT to have recognised those quotes especially
with you being nicked as "Scouser".

'fraid not. Obviously some part of popular culture has passed me by.
In this case it doesn't sound like I've missed much.
 
N

Nick Keighley

There is nothing sadder than someone who thinks people give a shit about
who or what he/she killfiles. Why do you do it?

to annoy you.
PLONKing is ancient usenet practice.
And you *KNOW* what a "Scouser" is.

yes, someone from Liverpool. And so? Look even if it *were* funny at
one point, saying it over and over again pretty soon leaches the
risidual humour from it.
 
J

Jon

Nick said:
I'm not convinced you do

you are not convinced I do what?
really? So produce some.

You think you are entitled to what?
Programming teams have to communicate a lot.

I got your "team" right here.
Someone has to extract requirements from customers. Programmers get
along in real life.

Said gestapo ?
it's not a "room" it's a usenet group.

As if you knew the difference.
it's possible for a rational person to hold an opinion that is not
completly in agreement with yours.

So stop picking on me.
no subtlety present. I was simply illustrating

pfft

:> that programmers have
to deal with things that aren't black and white.

as if you knew.
"too big" is a value
judgment not a defined number of lines with an error bar.

You are drunk.
you said he "wanted to be" an engineer. Where did he say that? You
implied that he had some sort of thwarted ambition.

Did I do that?
And wanted to work
for a cool engineering company like NASA or Microsoft.

Ain't no fuciking engineer in his right mind
Is NASA still
cool? Was Microsoft ever cool?

My job title is "Software Engineer" so I call myself an engineer on
even days and computer programmer on odd days. No I don't have a
professional engineering qualification.

I believe you. Surely that is correct.
 
K

Keith Thompson

Kenneth Brody said:
On 10/29/2010 5:28 PM, Keith Thompson wrote:
[...]
It's FILE, not FILE*, that can't be an incomplete type.

(The above statement is true, but was based on a misunderstanding
of a previous post.)
Well, I have to admit that, years ago, I had the need to do just
that. I needed a way to determine "is there anything for fread()
to read?" While there are POSIX ways to determine if there is
anything ready to read on the "file descriptor" associated with
the FILE*, there isn't any (AFAIK) standard way to determine if
there was something already in the FILE*'s buffer.

The code was, of course, kept in a platform-specific module.

And it could easily have been broken by the next version of the
C standard library on the very same platform (something of which
I'm sure you're well aware).
 
K

Kenny McCormack

Keith Thompson said:
And it could easily have been broken by the next version of the
C standard library on the very same platform (something of which
I'm sure you're well aware).

Which somehow didn't stop you from taking the time to post it.

Incidentally, 2+2=4 (something of which I'm sure you're well aware).

--
No, I haven't, that's why I'm asking questions. If you won't help me,
why don't you just go find your lost manhood elsewhere.

CLC in a nutshell.
 
K

Kenny McCormack

I...think...he...might...have...posted...it...for...the...benefit...of...others...than...Kenneth.

Well, then, so did I. You know, they don't teach arithmetic in the
schools anymore...
 
N

Nick Keighley

You waste hours reading comp.lang.c looking for opportunities to pounce and
show that you're witty and clever.

You usually mistake the opportunities because you know nothing about people
and their motives, and then when you do pounce, you're not even witty or
clever, just petulant.

That must really suck.

most of us worked this out long ago
 
B

BartC

Frijj said:
You waste hours reading comp.lang.c looking for opportunities to pounce
and show that you're witty and clever.

KM provides an entertaining, alternate viewpoint in this newsgroup.
 
T

Tim Rentsch

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.

Excellent observation, sir! I think this pretty much
settles the question of whether _Bool can have values
other than 0 or 1, let alone the extremely minor side
issue regarding size_t.
 
T

Tim Rentsch

Ben Bacarisse said:
Tim Rentsch said:
Ben Bacarisse said:
[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).

I think your analysis about what value would be passed is
correct. That wouldn't necessarily cause the implementation
to be non-conforming, except that the question has been
rendered moot by dSpam's observation about the inconsistency
of _Bool having a width greater than 1. I give. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,083
Messages
2,570,589
Members
47,211
Latest member
JaydenBail

Latest Threads

Top