Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > [META] Talking about talking about C.

Reply
Thread Tools

[META] Talking about talking about C.

 
 
Jon
Guest
Posts: n/a
 
      10-26-2010
Seebs wrote:
> On 2010-10-25, Kenneth Brody <(E-Mail Removed)> wrote:
>> On 10/23/2010 4:54 PM, MartinBroadhurst wrote:
>>> On 23 Oct, 19:44, Seebs<(E-Mail Removed)> wrote:

>
>>>> Engineers suck at communicating.

>
>>> No, everyone sucks at communicating.

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


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.


 
Reply With Quote
 
 
 
 
Jon
Guest
Posts: n/a
 
      10-26-2010
Keith Thompson wrote:
> Seebs <(E-Mail Removed)> writes:
>> So, watching the typedef battles, something has become clear to me.
>>
>> Engineers suck at communicating.
>>
>> Underneath it all, 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*. 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.
>>
>> One of the most useful non-engineering skills I've ever applied to
>> engineering is learning to communicate better. Interestingly,
>> writing clearly, while certainly useful, is by far the lesser part
>> of this. The big thing is to learn to listen better. And I still
>> have a long way to go on that.
>>
>> A friend of mine gave me an excellent summary of a useful tactic
>> when someone who is otherwise apparently pretty rational or
>> well-informed 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*.
>>
>> That's certainly contrary to the way engineers usually think!
>> However, it's very useful.

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


 
Reply With Quote
 
 
 
 
Jon
Guest
Posts: n/a
 
      10-26-2010
Seebs wrote:
> On 2010-10-24, Jorgen Grahn <(E-Mail Removed)> wrote:
>> I don't think it's just me and my superior mind -- I think the
>> perils of very concrete mental models are exaggerated.

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


 
Reply With Quote
 
dSpam@arcor.de
Guest
Posts: n/a
 
      10-27-2010
On 24 Okt., 00:08, Keith Thompson <(E-Mail Removed)> wrote:
> (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).
--
Dietmar Schindler
 
Reply With Quote
 
Joachim Schipper
Guest
Posts: n/a
 
      10-27-2010
Seebs <(E-Mail Removed)> wrote:
> On 2010-10-24, Keith Thompson <(E-Mail Removed)> wrote:
>> Seebs <(E-Mail Removed)> writes:
>> [...]
>>> (...) [i]t seems that the extended types have to use
>>> identifiers reserved for any use (footnote 2. 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
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      10-27-2010
Seebs <(E-Mail Removed)> writes:

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

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-27-2010
Tim Rentsch <(E-Mail Removed)> writes:

> Seebs <(E-Mail Removed)> writes:
>
>> [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.

--
Ben.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      10-27-2010
Ben Bacarisse <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
>> Seebs <(E-Mail Removed)> writes:
>>
>>> [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.
^^^^^^^^^^^^^^^^^^^^^^

 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      10-27-2010
On 2010-10-27, Joachim Schipper <(E-Mail Removed)> wrote:
> 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
--
Copyright 2010, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      10-27-2010
Tim Rentsch <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>
>> Tim Rentsch <(E-Mail Removed)> writes:
>>
>>> Seebs <(E-Mail Removed)> writes:
>>>
>>>> [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).

--
Ben.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: MVP's pls help.. 2 PC's not talking... Ack =?Utf-8?B?Q2hpYWN0b3I=?= Wireless Networking 0 02-04-2006 06:35 PM
4 computers 2 not talking to each other Carol Wireless Networking 8 12-30-2005 06:11 PM
Netscreen-Remote client talking to Cisco VPN 3005? Road Rage Cisco 0 05-11-2005 03:26 PM
ATM links not talking polifemo Cisco 1 10-20-2003 02:28 PM
where can I find book/resources talking about DSP design using VHDL? walala VHDL 1 09-01-2003 09:54 AM



Advertisments