Urgent C Questions

[Richard Heathfield]

Chris Hills said:

ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.

Not at all. If ISO wants to issue a new standard for C, that's fine - it
will become topical here. If that includes library calls for interfacing
with USB devices and for validating holographic security devices on Disney
videos, that's fine too. If it's part of the standard C language or
library, it's topical here.

Where will the pedants here go if items are dropped from ISO C? By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...

So what? All versions of ISO C are topical here. It'll just mean that we
have to say things like "well, you can't do such-and-such in C90, but
there is a way if you have C99 - but if you've got the latest, greatest C
XP or C Vista or whatever it's called, you can't do it any more because it
was dropped". Wordy, but doable.

I expect It will probably get left in so as not to break a lot of
existing code.

There are those who would argue that any code containing a gets call is
already broken.

 

[Chris Hills]

There are those who would argue that any code containing a gets call is
already broken.

Legally broken? ))

 

[Richard Heathfield]

Chris Hills said:

Legally broken? ))

It's a fair question. I would argue that any commercial (i.e.
written-for-money) C code written since 1988 that contained a call to
gets() would lay its author open to a charge of negligence. I don't know
whether it would constitute grounds for dismissal (or transfer to
Marketing), but it certainly ought to.

 

[Chris Hills]

Chris Hills said:


It's a fair question. I would argue that any commercial (i.e.
written-for-money)

Why only written for money code?

C code written since 1988 that contained a call to
gets() would lay its author open to a charge of negligence.

Many things should but they don't. Not using static analysis for one.

I don't know
whether it would constitute grounds for dismissal (or transfer to
Marketing), but it certainly ought to.

BTW isn't that a cruel and unusual punishment that might in other
quarters be called torture? Transferring to marketing that is.

 

[Richard Heathfield]

Chris Hills said:

Why only written for money code?

For the same reason that, if a swimming-pool attendant pours soap powder
into his private swimming pool until it goes all gloopy, that's his
affair. If he does it at work, he's liable to get into trouble.

Many things should but they don't. Not using static analysis for one.

Yes, there's a whole bunch of things that all C programmers ought to know,
do, and indeed not do. One might almost say that discussing such things is
the raison d'etre of comp.lang.c.

BTW isn't that a cruel and unusual punishment that might in other
quarters be called torture? Transferring to marketing that is.

IIRDilbertC, standard practice is to give the victim - um, sorry, employee
- three straight Gs&T (heavy on the G, light on the T) and a hard slap on
the face. Presumably this is a form of anaesthesia.

 

[Chris Hills]

Chris Hills said:


For the same reason that, if a swimming-pool attendant pours soap powder
into his private swimming pool until it goes all gloopy, that's his
affair. If he does it at work, he's liable to get into trouble.

I see that logic, what you do in the privacy of your own programs etc.
However Open Source and PD programs are often not written for money. (I
was not trying to get into a FOSS debate)

Yes, there's a whole bunch of things that all C programmers ought to know,
do, and indeed not do. One might almost say that discussing such things is
the raison d'etre of comp.lang.c.

Yes but you are talking about real world programing not Standard C,
static analysis is not part of ISO C

IIRDilbertC, standard practice is to give the victim - um, sorry, employee
- three straight Gs&T (heavy on the G, light on the T) and a hard slap on
the face. Presumably this is a form of anaesthesia.

 

[Richard Heathfield]

Chris Hills said:

I see that logic, what you do in the privacy of your own programs etc.
However Open Source and PD programs are often not written for money. (I
was not trying to get into a FOSS debate)

Neither was I. And you do have a point, insofar as the quality of many
Open Source and PD programs is a bit dire. Not all, maybe not even most -
but certainly many.

Yes but you are talking about real world programing not Standard C,
static analysis is not part of ISO C

Well, you introduced that subject, not me. Such things as static analysis
are perhaps more within the purview of comp.programming - I was referring
specifically to the things that ***C*** programmers ought to know, do, and
avoid.

 

[Randy Howard]

There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top of
it.

That is pretty interesting. It's not often that a tech body has the
spine to admit in so public a fashion that their last product was in
need of a good bulldozing.

What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."

Just go back to C95 and leave it the hell alone.

ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.

"real world C" means more than one thing, imo. Those that are working
on things that need to run on a lot of different platforms tend to be
more of a stickler for the sandbox model where you only do the things
guaranteed to be valid pretty much everywhere, and if you must jump
outside that, you do it by breaking out the nonstandard pieces and port
the implementation to each platform with conditional code (often behind
an abstraction API).

Another group of "real world C" programmers only care about one, or a
very limited number of platforms, and will write in a variant of C that
is known to work for those, and don't care one way or the other if it
runs on a DS9K, or even a recent OS they don't support.

In both of those cases, existing C compilers are "plenty good". Often
compiling either their own "variant", like stock gcc without the
conformance switches turned on, or strict C89/90/95 conformance enabled
gets both goals achieved.

Neither group needs to see the C standard change much, if at all.

There is another group though that wants C to be more of a true subset
of C++, for reasons that I have never shared. You may have a different
take on it, but getting two different standards bodies to make a
serious attempt at that happening seems unlikely. The very fact that
two different bodies are responsible for it pretty much demonstrates
that yes, in fact they are different languages, and that's fine. It
seems ludicrous to spend a lot of effort to make them more directly
linked just because the names of the languages are very similar.

Where will the pedants here go if items are dropped from ISO C?

I hate to break the news to you, but almost all of the "real world C"
crowd doesn't care one way or the other what the C committee does
anymore. They had all they really needed to get their job done in
1989. The "pedants" will probably be forced to start complaining about
code that is not C20xx clean. And if no compilers are available for it
a decade later, they'll be very lonely, just like the C99 pedants are
today.

By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...

If this C20xx standard comes to pass, it'll probably be yet another $18
(or quite a bit more for a while, then getting reduced when nobody buys
it to $18) pdf file, which will be quietly ignored by the compiler
vendors.

It's possible that something magical will happen, and everything wrong
with C99 will disappear, and everything good about it will stay around,
plus a few new things of value will appear, and gcc, icc, msvc, and 20
or 30 embedded compilers will all move to adopt it ASAP; the programmer
community will all clamor for it and start a mass email and telephone
campaign to the vendor of choice. It's also possible that my local dog
catcher will be named as Imperious Overlord of the Planet by universal
world acclaim. Both are about equally likely.

I expect It will probably get left in so as not to break a lot of
existing code.

So it'll be another joke. Hint: All three programs in the world that
use gets() in a perfectly safe way can be modified in a matter of
minutes to work without it, and all the remainder are broken already.

The notion that "we don't want to break code by removing a feature that
makes it almost impossible for it not to be broken by default" is one
of the more silly things I've seen done outside of government.

 

[Keith Thompson]

There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top
of it.

What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."

[...]

I'm not unsympathetic to the idea, but I foresee some serious
problems.

A link was posted recently to a list of several compilers that have
been certified as C99 compliant, including Sun's compiler. (I don't
have the URL; perhaps somebody else saved it.) If that list is
accurate, then the set of features "implemented by more than two
mainstream compilers" may well already be the full C99 language.

The next C++ standard is expected to incorporate a number of C99
features (see above). Is the C committee coordinating with the C++
committee on this issue? What happens if C++ requires support for
<ctgmath>, but C drops <tgmath.h>?

I know you've said before that you don't have any detailed information
on this. Please let us know when you have something more definite.

 

[Kaz Kylheku]

The post from Jack is a classic example of why c.l.c  is getting such a
bad name for itself.

Yes, you show that you really do know Jack.

It is valid C... just not strictly conforming .

If it's not strictly conforming, it might be something valid, just not
C. It might be a valid program in some nonstandard C dialect.

A given C implementation can accept just about anything. So according
to your logic, this is valid C (just not strictly conforming):

void atomic_add(int * operand, int incr)
{
__asm__ __volatile__ ("lock xaddl %1, %0\n" : "m" (*operand),
"r" (incr));
}

The problem wuith this reasoning is that /anything/ is then valid C
(just not strictly conforming).

If your C compiler accepts files with a .pas suffix as Pascal, hey,
they are valid C, right? Because it's a C compiler after all.

How does it's undefined behaviour impinge on the question asked?

The undefined behaviors completely destroys the validity of the entire
examination, as well as the credibility of anyone using it to evaluate
someone's C knowledge!

It is valid C... for reasons of brevity the headers were not included.

No, it's obviously for reasons of ignorance that they weren't
included.

You are way, way too charitable, beyond the healthy level demonstrated
by someone mentally healthy and self-confident. If this is your
attitude, you're basically going to be a push-over all your life,
stuck working with idiots, forgiving their mistakes, taking blame,
etc. If you ever become a manager, you won't have the guts to weed out
the morons, and your competent underlings will hate you and work
around you.

Fact is, these questions were written by someone who has absolutely no
place probing and evaluating other people's knowledge of the subject
matter, and the right human instinct thing to do is to call it out.
(Of course, whether one should immediately cave in to that instinct,
and the timing and manner, depends on the circumstances).

However your pedantry is irrelevant to answering the question at hand.

Pendantry is perfecly relevant in computer science. We are not
discussing the choice of choreography in someone's interpretive dance.

Why?

That's covered in the same document where you learned to misunderstand
``strictly conforming''.

No the OP is ignorant. You are just insulting and not much of a person.
Try communicating with people occasionally.

The OP didn't write that code. Try reading comprehension
occassionally.

The OP was unfairly confronted with the code as a way of assessing
what he knows.

They are but you don't have the breath of intelligence or common sense
to understand. You must be a liability if you have to work with humans,

What about being a liability when your job is to work with precise
machines?

What is relevant here, in human terms, is that some clueless assholes
are assuming the position of being able to evaluate someone else's
competence, when they don't know the subject matter themselves.

If this is a school exam, it means that this poster was taught by
monkeys. He must reproduce their bullshit faithfully in order to earn
the best grade.

Ignore Jack.

... but do listen to someone who doesn't know why x = x++ is
undefined?

Now there is a plan.

 

[CBFalconer]

.... snip ...

ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here
who want only ISO C as described in all versions of ISO/ANSI C
and K&R but not as used in reality.

Where will the pedants here go if items are dropped from ISO C?
By the current definition of what C is from most of them it will
include C99 and therefore things that are no longer legal...

Already there. Try using implicit int typing in C99. This means
that compilers need to use the gcc technique of adopting the
appropriate standard at compile time. There are also things to do
with modulus and division. Probably more.

In general it will be hard drop things that cannot be implemented
in other legal ways.

 

[CBFalconer]

.... snip ...

So it'll be another joke. Hint: All three programs in the world
that use gets() in a perfectly safe way can be modified in a
matter of minutes to work without it, and all the remainder are
broken already.

I maintain that all use of gets can be safely replaced with ggets
with minor source adjustments. ggets is written in standard C, and
is freely available at:

<http://cbfalconer.home.att.net/download/>

 

[Richard Heathfield]

Kaz Kylheku said:

If this is a school exam, it means that this poster was taught by
monkeys. He must reproduce their bullshit faithfully in order to earn
the best grade.

He can't reproduce it, because they can't produce it in the first place.
All they can produce is monkeyshI'll get my coat.

 

[Chris Hills]

There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top
of it.

What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."

[...]

I'm not unsympathetic to the idea, but I foresee some serious
problems.

A link was posted recently to a list of several compilers that have
been certified as C99 compliant, including Sun's compiler. (I don't
have the URL; perhaps somebody else saved it.) If that list is
accurate, then the set of features "implemented by more than two
mainstream compilers" may well already be the full C99 language.

OK they probably mean widely used.... There are some features that were
added for specific areas that most don't use in practice. .

The next C++ standard is expected to incorporate a number of C99
features (see above). Is the C committee coordinating with the C++
committee on this issue? What happens if C++ requires support for
<ctgmath>, but C drops <tgmath.h>?

God knows.

I know you've said before that you don't have any detailed information
on this. Please let us know when you have something more definite.

OK.

 

[Barry Schwarz]

1. in the prg bellow what vars are stored on stack, heap, data segment?

Only the documentation for your compiler can tell you. It is an
implementation detail that very few programs need to be concerned
about
..

int i;

void main()

Since you are using an implementation specific extension of the
language, you would be better to ask in a newsgroup that deals with
your implementation.

{
int j;
int *k = (void *)malloc(1);

The only purpose served by this cast is to suppress the mandatory
diagnostic that this code invokes undefined behavior due to the
missing prototype for malloc.

}

(I think j and k are on stack, but where is i?)


2. how to find sizeof variable w/o using sizeof command?

(no clue)

Think of the only way you can create two variables that are guaranteed
to be adjacent in memory. Then subtract the address of the second
from the address of the first (treating both as pointer to char) to
get the size.

3. what is the o/p of this prg?

void main()
{
int x = 5;
x = x++;

This statement invokes undefined behavior. From this point forward,
there are no restrictions on what the generated code can do. There is
even no requirement that the code behave consistently on repeated
executions.

printf("x=%i", x);

This statement also invokes undefined behavior due to a missing
prototype.

}

(I think it shoulld be printing 5 but it prints 6!)

You need to think again. Read the description of the ++ operator very
slowly and carefully, particularly the part about side effects and
when they occur.

ps: I am using QuickC 2.0

We deal with standard features of the language here. Implementation
details are best asked in a group that discusses the particular
implementation.

pps: Is very urgent!

Not to me it's not. If it was to you, you should realize that Usenet
is not like a chat room where messages are delivered in near real
time. Messages frequently take days to propagate.

You could also have googled the archive of this newsgroup since these
questions are asked several times a year. (Do you really think your
instructor is the only one to assign really stupid homework
questions?) In fact, there is still a senseless debate raging over
whether a C system must have a stack that started the last time your
first question was asked.


Remove del for email

 

[James Kuyper]

CBFalconer wrote:
....

FYI <iso646.h> was added to C90 in 1995.

My apologies - I have a copy of the C99 standard, but I've never owned a
copy of C90, so I'm not as clear as I'd like to be about which features
were first introduced in C99. The C90 standard was too expensive when I
needed it, and no longer of interest to me by the time it's price
dropped into a range where I could afford it.

 

[Army1987]

We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again.

It'll be C1x, fortunately.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1250.pdf