twitter: comp.lang.c - 25 new messages in 13 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: quistion
http://groups.google.com/group/comp.lang.c/t/525dfac9e8523a80?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 10:24 am
From: Seebs

On 2010-04-10, khan <yousafshah33@gmail.com> wrote:
> Hi..my name is yousaf shah khan. my quistion is....
> what is the differenc between globel and local variables?

It's a shame that your textbook is written in a language you're
too lazy to read.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 2 ==
Date: Sat, Apr 10 2010 11:36 am
From: Keith Thompson

khan <yousafshah33@gmail.com> writes:
> what are the operators and expression of C PROGRAMMING languge?

Please tell your instructor and fellow students at IUT that asking
elementary questions like this in a newsgroup is a very bad way to
learn the language, and that those of us who actually participate in
the newsgroup are becoming quite annoyed.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"

==============================================================================
TOPIC: same struct, but different size.
http://groups.google.com/group/comp.lang.c/t/fa87400135aae641?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 10:25 am
From: Seebs

On 2010-04-10, Control Freq <nick@nhthomas.freeserve.co.uk> wrote:
> I see that a struct is defined a the top of two files, unit1.c and
> unit2.c .
> But, the struct has the same name, but the struct in unit2.c has more
> elements.

> A function in unit2.c takes a pointer to the struct as an arg, and the
> function is called from unit1.c .

Sounds bad.

> But, why didn't the compiler warn me about this problem? I presume
> it's a linker issue rather than a compiler issue. But, is there any
> way of getting the compiler to throw an error when this happens?

Yes! You declare the structure, once, in a single header, and every file
includes that header.

> There are many code files to check through, it's going to take ages to
> check them all!

Move the declaration into a header, add the header to everything, and you'll
get errors.

Also, warn the people in charge (management or whatever) *NOW*. Warn them
that the program is dangerously badly written at a level that implies
massive failure to understand C, and that any estimates they have for how
long things will take are going to be too short. They may not like hearing
it, but you might as well tell them in advance.

==============================================================================
TOPIC: seebs/schildt
http://groups.google.com/group/comp.lang.c/t/0c84debf9a4f144b?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 10:26 am
From: Seebs

On 2010-04-10, blmblm myrealbox.com <blmblm@myrealbox.com> wrote:
> Over and over Nilges talks about your "backstabbing". Do you have
> any idea what he means by that? It must be a reference to something
> you said at some point, but I can't remember anything that would
> fit, and I'm starting to be more than a little curious. Answer
> not required, of course.

I think he has some sense that there is an implicit brotherhood of all
people who know even a little C, such that it is a horrible crime against
humanity for one of them to suggest that another isn't doing the most
perfect of all possible jobs.

... If it's not that, I got nothing.

== 2 of 2 ==
Date: Sat, Apr 10 2010 10:27 am
From: Seebs

On 2010-04-10, Richard Harter <cri@tiac.net> wrote:
> If you appreciate ambiguity you may enjoy this: Suppose you are
> at a party that is a dead bore. As you leave your hostess looks
> at you expectently as she gushes at you. Clearly politeness
> requires that you tell you had a wonderful time. Equally
> clearly, honesty forbids you saying any such thing. Consider the
> merits of saying, "I must say I had a wonderful time."

And note how much more insulting it gets if you emphasize "must" instead
of "wonderful". :)

==============================================================================
TOPIC: seebs/schildt I
http://groups.google.com/group/comp.lang.c/t/9f0200c489f848f8?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Apr 10 2010 10:28 am
From: Seebs

On 2010-04-10, Moi <root@invalid.address.org> wrote:
> Humorless: only to them who don't understand programming.

Not even that. One of the reasons people in general get along with me
is that I'm actually pretty funny. Often intentionally!

== 2 of 3 ==
Date: Sat, Apr 10 2010 10:59 am
From: Sjouke Burry

Seebs wrote:
> On 2010-04-10, Moi <root@invalid.address.org> wrote:
>> Humorless: only to them who don't understand programming.
>
> Not even that. One of the reasons people in general get along with me
> is that I'm actually pretty funny. Often intentionally!
>
Now THATS REALLY funny!!!!!

== 3 of 3 ==
Date: Sat, Apr 10 2010 11:03 am
From: cri@tiac.net (Richard Harter)

On 10 Apr 2010 17:28:15 GMT, Seebs <usenet-nospam@seebs.net>
wrote:

>On 2010-04-10, Moi <root@invalid.address.org> wrote:
>> Humorless: only to them who don't understand programming.
>
>Not even that. One of the reasons people in general get along with me
>is that I'm actually pretty funny. Often intentionally!

I must say that your posts are often quite witty. :-)

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.

==============================================================================
TOPIC: What's the usage of char buf[0] as a structure element?
http://groups.google.com/group/comp.lang.c/t/3a0f52dabe6e06af?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 10:28 am
From: Seebs

On 2010-04-10, Kok How Teh <khteh73@gmail.com> wrote:
> Hi;
> I see many "char buf[0];" structure element used in linux kernel
> especially in include/net/*.h Could anyone explain what's the use of
> this "zero-element" array as an element in a structure? Thanks.

It's a pre-C99 version of a flexible array member.

==============================================================================
TOPIC: Generic linked list with internal storage?
http://groups.google.com/group/comp.lang.c/t/d36ff63bef634bcc?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 10:42 am
From: Tim Rentsch

Jef Driesen <jefdriesen@hotmail.com.invalid> writes:

> A typical (double) linked list is implemented with these two data
> structures:
>
> typedef struct node_t {
> node_t *prev;
> node_t *next;
> void *data;
> } node_t;
>
> typedef struct list_t {
> node_t *head;
> node_t *tail;
> } list_t;
>
> typedef struct mydata_t {
> ...
> } mydata_t;
>
> The major disadvantage of this approach is that the data contents of
> the list needs to be stored outside of the list data structures. Thus
> if you want to store some user defined data in the list, you end up
> with two memory allocations per node: one for the node_t structure,
> and one for the user defined mydata_t structure.
>
> Is there a way to avoid this additional allocation, but without
> loosing the ability to store custom data? Thus I don't want to tie my
> list to the mydata_t structure like this:
>
> typedef struct node_t {
> node_t *prev;
> node_t *next;
> mydata_t data;
> } node_t;
>
> Maybe allocate storage for the node_t and the mydata_t structure in a
> single block. Something like this:
>
> node_t *node = malloc (sizeof (node_t) + sizeof (mydata_t));
> mydata_t *data = node + sizeof (node_t);
>
> But I think this might cause trouble due to alignment issues?

Yes, it might. In fact, almost certainly will, if the code has
any significant longevity.

It is possible to do something along the lines of what you're
asking about. Very briefly, the list "header" has an additional
member that stores a byte offset of where the node value is
stored, and what numeric value is stored in this offset member is
computed using one of the standard techniques for determining
alignment of a type. Doing this reliably and portably requires a
lot of attention to details regarding not only alignment but also
the rules about storing into structure members and padding bytes.
(There are some other details about what type is being used and
what interface to supply to read or store the data, but I'm
skipping over these.)

A more significant question, I think, is are you really sure you
want to do this, given that it seems like you aren't completely
sure of how to do it so it works? It's easy to sidestep all the
difficulties, just by doing two allocations. Until you know how
to avoid the problems, and avoid them reliably, you're probably
not in the best position to decide whether the single allocation
approach is a good one. So I would suggest either just doing
two allocations, or making learning how to implement a "data
and list header together" approach a pre-requisite to deciding
whether you do, in fact, actually want to use such an approach
in your program(s).

==============================================================================
TOPIC: C the complete nonsense
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Apr 10 2010 10:39 am
From: Seebs

On 2010-04-10, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On 10 Apr, 18:15, Seebs <usenet-nos...@seebs.net> wrote:
>> All they've said is that they have not defined an outcome -- meaning
>> anything is permissible, not that nothing is permissible.

> Usually when the program is permitted to exit with an error message,
> it is said that the behaviour is "undefined". This is to keep the
> distinction that programs with implementation-defined behaviour are
> (or can be) correct, programs with undefined behaviour are incorrect.

The obvious exception would be abort(). :)

But yes, I think that's a pretty good summary. Undefined behavior
means you no longer have a reasonable expectation of *any behavior
at all*, let alone expected behavior. By contrast, unspecified
behavior means you are guaranteed to get some result, but no one
will tell you what. Implementation defined behavior means that,
if you look in the compiler documentation, you can find out exactly
what behavior you will get.

== 2 of 6 ==
Date: Sat, Apr 10 2010 10:57 am
From: Keith Thompson

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-04-10, Alexander Bartolich <alexander.bartolich@gmx.at> wrote:
>> Seebs wrote:
>>> [...]
>>> The key is that, in an expression, a function yields a value of its
>>> return type.
>
>> I would like to contribute to this game of finding the smallest nit.
>> *Calling* a function yields a value of its return type. The function
>> name itself (without the function call operator) yields a pointer to
>> the function.
>
> Right you are. My sentence, as written, was indeed incorrect. Good
> catch!
>
> (This kind of thing, by the way, is why people writing about C usually
> *need* technical reviews and errata.)

The most correct and precise way to say that is that a *function call*
(which is a kind of expression) yields a value of the function's
return type.

== 3 of 6 ==
Date: Sat, Apr 10 2010 11:07 am
From: Keith Thompson

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On 10 Apr, 10:33, SG <s.gesem...@gmail.com> wrote:
>> I just happened to skim through your recent blog post, spinoza1111,
>> and noticed the following:
>>
> [Is the "type" of a fucntion void or void(int)?]
>
> Generally we use the terms "signature" and "return type" to avoid this
> ambiguity.

What ambiguity?

The "type of a function" is always a function type, which is distinct
from the function's return type. You can talk about a function's
"signature" if you like (the standard never uses the term but I'll
concede that it's clear enough). But the "type of a function"
means one and only one thing.

I'll concede that some people refer to a function's return type
as the type of the function, and this can be fairly harmless in
informal discussions. But such usage is strictly incorrect, and
either using it in a C reference book or attempting to "correct"
someone who has used the terms correctly is just wrong.

> In some contexts ypu want to talk about the return type of a function,
> for instance in the expression
> printf("%f", foo() );
>
> foo() can be replaced by any function of "type" float or double.

No, the call to foo can be replaced by a call to any function
whose return type is float or double (i.e., whose type is "function
taking whatever and returning float or double") -- or by any other
expression of type float or double.

> On
> the other hand qsort takes a pointer to a comparison function of
> "type" int(const void *, const void *).

Yes -- except that you can drop the scare quotes; that really is
the type of the comparison function.

== 4 of 6 ==
Date: Sat, Apr 10 2010 11:14 am
From: Keith Thompson

Tim Rentsch <txr@alumni.caltech.edu> writes:
> cri@tiac.net (Richard Harter) writes:
[...]
>> In short, the C standards are incomplete; they do not completely
>> specify the interpretation of code.
>
> It is complete in this area. The Standard says specifically
> that order of evaluation is "unspecified", meaning any ordering
> that doesn't violate any other stated requirements is allowed.
>
>> One way to look at it is that
>> the standards specify C as a family of languages, differing by
>> implementation defined rules.
>
> Certainly that is one way to look at it. A better way (IMO) to
> look at it, at least as regards evaluation order, is that C
> is a single language with a non-deterministic semantics. One
> reason for this is that an implementation need not make the
> same choice about evaluation order from one expression to the
> next, or even the same on the next compilation as this one.
> And for evaluation order in particular, implementations are
> under no obligation to describe or document what rules they
> use to determine ordering in any particular circumstance.

Did you really mean to use the word "non-deterministic"?

I'd prefer to say that C is a single language whose semantics
are not entirely specified in all cases. Saying that it has
"non-deterministic semantics" could imply that each implementation
is required to behave in a non-deterministic manner, which of course
it isn't.

== 5 of 6 ==
Date: Sat, Apr 10 2010 11:24 am
From: Malcolm McLean

On 10 Apr, 19:07, Keith Thompson <ks...@mib.org> wrote:
>
> I'll concede that some people refer to a function's return type
> as the type of the function, and this can be fairly harmless in
> informal discussions. But such usage is strictly incorrect, and
> either using it in a C reference book or attempting to "correct"
> someone who has used the terms correctly is just wrong.
>
"type" is a C technical term. The problem is that we can't restrict
the word to this usage, even when discussing the C standard, because
it is too common an English word.

== 6 of 6 ==
Date: Sat, Apr 10 2010 11:25 am
From: Keith Thompson

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
> In article <018bdbb1-10b2-4102-94df-635bf7081823@h27g2000yqm.googlegroups.com>,
> spinoza1111 <spinoza1111@yahoo.com> wrote:
>> On Apr 10, 5:01 am, John Bode <jfbode1...@gmail.com> wrote:
>> > On Apr 9, 3:05 am, Seebs <usenet-nos...@seebs.net> wrote:
>> >
>
> [ snip ]
>
>> > Schildt's own writing compared to the language definition to
>>
>> The "language definition" as found in the standards cannot be used to
>> write compilers
>
> So the existence of compilers that claim to be standard-compliant ....
>
> Eh, why bother.

Yes, why bother????

[snip]

==============================================================================
TOPIC: Biographies of Living Persons issue re-opened for Herbert Schildt
http://groups.google.com/group/comp.lang.c/t/170bb25b2f0c7a61?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 10:54 am
From: Keith Thompson

Colonel Harlan Sanders <Harlan@kfc.com> writes:
[..]
> Anyway, you, or Nilges for that matter, are free to edit the article
> and add "balance" yourself, if you can find similarly reputable
> reviews that are positive to Schildt. Nilges' preferred option now,
[...]

Nilges can't; he's been banned.

== 2 of 2 ==
Date: Sat, Apr 10 2010 11:22 am
From: Colonel Harlan Sanders

On Sat, 10 Apr 2010 10:54:56 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Colonel Harlan Sanders <Harlan@kfc.com> writes:
>[..]
>> Anyway, you, or Nilges for that matter, are free to edit the article
>> and add "balance" yourself, if you can find similarly reputable
>> reviews that are positive to Schildt. Nilges' preferred option now,
>[...]
>
>Nilges can't; he's been banned.

He can't as "Spinoza1111", but he keeps editing anonymously.
Since he vandalises the same articles over and over, he gets detected
and reverted quickly. If however he made a positive edit and didn't
rant against his enemies, it would not draw attention. That's of
course just a theoretical possibility, since he can't stop himself.

The "issue" he refers to at the head of this thread, posted from an
anoymous IP, is pretty hilarious in that respect:

comment added by 121.202.68.35
>This week (ending 11 April 2010) Seebach has written a
>new attack on the fourth edition and he has changed the
>Schildt article to reference the new attack in order to
>cover his tracks, after a considerable amount of
>criticism on comp.lang.c this year, coming from
>independent and educated sources.
>
>Under Biographies of Living Persons, wikipedia is being
>used to enable a personal campaign of malicious libel.

... and so on and on and on....

==============================================================================
TOPIC: struct assignment and indeterminate values
http://groups.google.com/group/comp.lang.c/t/c15233bd771f1091?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 11:09 am
From: Tim Rentsch

Seebs <usenet-nospam@seebs.net> writes:

> While reading up on some of the stuff in C:TCR, I've found something which
> looks as though it used to be an error but possibly isn't.
>
> Consider:
> int main(void) {
> struct { int a, b; } x, y;
> x.a = 10;
> y = x;
> return 0;
> }
>
> Is the behavior of this program well-defined? My assumption would have been
> that it was not, because x.b was indeterminate and accessed through an lvalue
> of non-character type. However, C99 TC3 says (6.2.6.1, paragraph 3):
> "the value of a structure or union object is never a trap
> representation, even though the value of a member of the structure
> or union may be a trap representation".
>
> That looks as though, after the assignment, no undefined behavior has occurred,
> but it is possible that y.b is a trap representation. Interestingly, it looks
> as though this might be true even if y had been fully initialized before the
> assignment from x.
>
> Thoughts?

The value of a structure is NEVER [my emphasis] a trap representation.

Hence, the assignment 'y = x;' is always defined, even if
any _or all_ of the members of 'x' hold trap representations.

(There is a change in C1X that would let 'y = x;' be undefined
behavior (I think) if no assignment has been done to a member
of 'x'. However, this code

struct { int a, b; } x[1], y[1];
y[0] = x[0];

is always defined behavior, even with no member assignments
to 'x[0]', even under the new C1X rules.)

==============================================================================
TOPIC: lvalues and rvalues
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 11:18 am
From: Tim Rentsch

SG <s.gesemann@gmail.com> writes:

> Tim Rentsch wrote:
>>
>> If we have
>>
>> int x[10][20];
>>
>> then 'x[y]' is not an lvalue.
>
> Not true. &x[y] is valid and yields a pointer of type int(*)[20].
> Since the unary & requires an lvalue expression operand x[y] cannot be
> an rvalue. In fact, it is an lvalue of type int[20]. Array-to-pointer
> decay only happens if it's used in a context where an rvalue is
> needed. [snip]

Of course what I meant was 'x[y]' as an expression by
itself is not an lvalue. In the context of '&x[y]'
the sub-expression 'x[y]' is an lvalue, but I was
speaking of 'x[y]' not in that context.

I don't mind being corrected, but please don't
deliberately misunderstand me to supply a
"correction".

== 2 of 2 ==
Date: Sat, Apr 10 2010 11:38 am
From: Keith Thompson

Joe Wright <joewwright@comcast.net> writes:
> On 4/10/2010 00:00, Keith Thompson wrote:
[...]
>> Case 1:
>>
>> int x;
>> /* The expression ``x'' is an lvalue. */
>>
>> Case 2:
>>
>> enum { x };
>> /* The expression ``x'' is not an lvalue. */
>>
>> In many cases ("very nearly" may have been an overstatement), you can
>> tell whether a given expression is an lvalue or not just by looking at
>> it. ``*x'' and ``x[y]'' are lvalues; ``&x'' and ``2+2'' are not.
>>
> So now 'many cases'. Can you give an example of an expression whose
> 'lvalueness' cannot be determined by simple inspection?

Look up a few lines. You see that expression ``x''? Can you
determine whether it's an lvalue by simple inspection?

Isn't that exactly what I was just saying?

==============================================================================
TOPIC: C - gets() function implementation help
http://groups.google.com/group/comp.lang.c/t/7bd0bc765a2e9603?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 11:21 am
From: Keith Thompson

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> As others have pointed out, gets() will (probably) crash if you pass
> it a buffer shorter than the line you read. Given the specifications,
> there's no way to prevent this behaviour, so think of it as an
> undesireable feature rather than a bug.

Or think of it as a bug in the requirement, rather than a bug in your
code.

==============================================================================
TOPIC: C progreamming
http://groups.google.com/group/comp.lang.c/t/fc9113386afdfc9b?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Apr 10 2010 11:23 am
From: Keith Thompson

saif raihan <saifraihan.lc@gmail.com> writes:
> Hi,
> I am Saif Raihan. Ihave a question:
>
> " What is String?"
>
>
> Any answer will be granted.

Let me guess: you're a student of IUT.

Tell your instructor, or whoever gave you the idea that this is a good
way to learn, that they're wrong.

== 2 of 2 ==
Date: Sat, Apr 10 2010 11:39 am
From: ike@localhost.claranet.nl (Ike Naar)

In article <fbd1d181-6c20-451a-9be2-29e4ae370e45@i25g2000yqm.googlegroups.com>,
saif raihan <saifraihan.lc@gmail.com> wrote:
>I am Saif Raihan. Ihave a question:
>" What is String?"

You will find useful information in chapter 8 of the C FAQ:
http://c-faq.com/~scs/cclass/notes/sx8.html

==============================================================================
TOPIC: c programming
http://groups.google.com/group/comp.lang.c/t/bb4a7a5de0028d17?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Apr 10 2010 11:24 am
From: Keith Thompson

Seebs <usenet-nospam@seebs.net> writes:
[...]
> p.s.: If you wanted to ask about a C language feature, you might have been
> thinking of "pointer", lowercase. In English, capital letters on nouns
> that aren't at the end of a sentence indicate a proper noun, such as a dog
> breed.

s/end/beginning/

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Saturday, April 10, 2010

comp.lang.c - 25 new messages in 13 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts