what is difference between sizeof and strlen

[Keith Thompson]

2 variants: either it works or it does not. And only one of them will be
chosen on some particular system/compilator. I would not call it "undefined
behaviour", it's quite defined for a platform. And I just want to know the
name of the platform where it does not work. Could you enlighten me?

void main() is actually an unusual case, and perhaps not the best one
for illustrating the concept of undefined behavior.

The standard explicitly allows an implementation to define the
behavior of alternative definitions of main(), including void
main(void), but it does not require any implementation to do so. For
an implementation whose documentation *doesn't* mention void main(void),
the behavior of
void main(void){}
is undefined (see also "nasal demons"). For an implementation that
*does* explicitly document it, the behavior is implementation-defined.

In a sense, the extra permission given by the standard is redundant,
since an implementation is free to document anything it likes,
including defining the behavior of constructs that, as far as the
standard is concerned, invoke undefined behavior.

In a way, it's similar to what happens on integer overflow. The
following code fragment:

int i = 32767;
i ++;

invokes undefined behavior under an implementation with
INT_MAX == 32767, but is well defined where INT_MAX > 32767.

Bottom line: always use one of the standard definitions of main()
unless you have a very good reason not to. Saving a few keystrokes is
not a very good reason. Using a freestanding implementation (most
likely an embedded system) may be a very good reason.

In response to comments made elsewhere in this thread, none of this
has anything whatsoever to do with "religion". We are simply giving
you the best advice we can. If this comes across as "You must do
things this way because you'll go to Hell if you don't!", please feel
free to ask for clarification. There's almost always a valid reason
for the advice we give, but we don't always necessarily make that
sufficiently clear.

 

[Kenneth Brody]

I don't get it. I thought, and I still continue to think, that "undefined
behaviour" means just that: when the behaviour is undefined. If the
behaviour is dependent on some defined thing (platform) then it's
"defined". You (or I) just need to know the platform. Of course, there's no
such (defined) thing as "platform" in C standard, so they say "undefined
behaviour". "int main()" is a tough religion, isn't it?

If the standard says that the implementation needs to define something
(for example, the size of an int), then it's "implementation defined".
If the standard places no constraints whatsoever (such as "i = i++")
then it's "undefined behavior".

Yes, a particular implementation may define what the "undefined behavior"
is on that aprticular implementation, but it's still undefined as far as
the standard goes.

Yes, the odds are that a given implementation's actions and a piece of
code that invokes undefined behavior will probably be consistent, even
if the implementors don't define it. But nothing requires it to be,
and it may change in the next release, even if it's a minor update,
like an update from 5.1.234.98 to 5.1.234.99 release. (Even an
implementation defined behavior can change, but it's not likely to
change in anything but a major version upgrad.)

For example:

#include <stdio.h>

int main(int argc,char *argv[])
{
float a, b, c;

c = a / b;

printf("%ld\n",c);

exit(EXIT_SUCCESS);
}

It may be that the particular implementation ensures that you will
get some sort of "divide by zero" abort. On the other hand, many
platforms are likely to give you "random" results, depending on
what happens to be in the memory used for the "a" and "b" floats.
Even if the platform has well-defined behavior for divide-by-zero,
floating point over/underflow, and so on, the only "definition" to
the behavior would begin "if the memory happens to contain..."

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Kenny McCormack]

"Undefined behaviour" is a technical term in the C standard. It's not
really relevant whether *you* would call it that.

-- Richard

Probably not relevant to *you* (Richard), but certainly relevant to Anton.

I'd wager, in fact, that whether or not Richard thinks something is
"undefined behaviour" is about as relevant to Anton as is whether or not
Anton thinks something is "undefined behaviour" is to Richard.

 

[Kenny McCormack]

How long are you going to keep this crap up? Soon your pseudo-anarchism
and childish name-calling will land you in multiple killfiles.

Define "pseudo-anarchism" in this context. In the sense that you are using
it, how is it different from (real) anarchism? Why the distinction?

 

[Kenny McCormack]

In response to comments made elsewhere in this thread, none of this
has anything whatsoever to do with "religion". We are simply giving
you the best advice we can. If this comes across as "You must do
things this way because you'll go to Hell if you don't!", please feel
free to ask for clarification. There's almost always a valid reason
for the advice we give, but we don't always necessarily make that
sufficiently clear.

I'm going to say this briefly and hope that the more intelligent readers
can fill in the blanks and not worry about the lack of all the lawyerly
bells and whistles that are ordinarily necessary.

The content of this ng is religious in the sense that it has to do with the
contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*). Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.

I think the point is not so much that any particular thing (such as that
which is currently under discussion) is a matter of religion as that the
entire scope and charter of this ng is much more in line with a religious
framework than that of a scientific one.

And that's a strange thing to find in an ng under the comp.* hierarchy.

(*) Equivalently: "They do move".

 

[Gordon Burditt]

The content of this ng is religious in the sense that it has to do with the

contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*). Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.

Problems with void main() are observable. When I use such a program
in a Makefile, it usually blows off the make with an error, because
it returns status that looks like an error to make.

Gordon L. Burditt

 

[Alan Balmer]

I'm going to say this briefly and hope that the more intelligent readers
can fill in the blanks and not worry about the lack of all the lawyerly
bells and whistles that are ordinarily necessary.

The content of this ng is religious in the sense that it has to do with the
contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*).

No scientist would accept this as proof that void main() works just
fine in another environment, or even at another time. It says only
that this particular use, in this particular program, on this
particular implementation, with the particular inputs used, worked as
many times as I tested it. Any extension of this religious belief must
be based on faith.

Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.

But nobody here is saying that. What we are saying is that the
standard does not define what it does. That's an observable fact, as
scientific as it gets. Proof requires only that one read the standard.

 

[Anton Petrusevich]

and since the latter is portable, there is no advantage in using the
former.

Good point. This is just my experience that says me: "I have never seen a C
compiler which generated different symbols for void main() and for int
main()". And so in my mind it's not a big deal which defenition to use.

There's nothing religious about it. It's a matter of correctness
about which there are strong feelings, largely because certain people
and/or institutions have encouraged something that is incorrect for no
good reason.

If you would call ANSI/ISO C standard as "Bible"...

Perhaps the word "religious" doesn't mean what you think
it means. (And if you want to discuss that further, please take it to
alt.usage.english.)

Is my English so bad?

 

[Mark McIntyre]

This is just my experience that says me: "I have never seen a C
compiler which generated different symbols for void main() and for int
main()".

I have, and so have many others in this group. On at least one machine
I've used, void main() would cause the app to crash on exit, and/or
generate random error messages on the console.

If you would call ANSI/ISO C standard as "Bible"...

In this group, the ISO standard /is/ the Bible.

Is my English so bad?

its okay, I've read much worse.

 

[Richard Tobin]

Probably not relevant to *you*

I would have thought it was obvious that I meant relevant to the
behaviour and correctness of C implementations, not to any one person.

-- Richard

 

[Keith Thompson]

The content of this ng is religious in the sense that it has to do with the
contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*). Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.

I think the point is not so much that any particular thing (such as that
which is currently under discussion) is a matter of religion as that the
entire scope and charter of this ng is much more in line with a religious
framework than that of a scientific one.

And that's a strange thing to find in an ng under the comp.* hierarchy.

(*) Equivalently: "They do move".

No.

What we do in this newsgroup isn't "science" in the sense of
formulating hypotheses and theories and testing them by performing
experiments in the real world and observing the results.

It's more like mathematics, in which we start from a set of postulates
and rules of inference and reason from them to reach conclusions.

As far as "void main" is concerned, the standard does *not* say that
it doesn't "work". To see what it does say, read any number of
articles in this thread -- or read the standard itself.

Arguing about whether void main() "works" in comp.lang.c is not unlike
arguing about whether parallel lines can meet in Euclidean geometry.
It is a fact that parallel lines cannot meet in Euclidean geometry,
because that's one of the postulates on which it's built. It's also a
fact that "parallel" lines can meet in some non-Euclidean geometries
-- but then you're not talking about Euclidean geometry anymore.

It is, of course, possible to discuss the relationship between
Euclidean geometry and the real world (is space curved?), but strictly
speaking that's not a discussion about Euclidean geometry. Similarly,
it's possible to discuss the relationship between C and the real world
(does gcc conform to this section of the standard?), but again,
strictly speaking that's not a discussion of C, which is what this
newsgroup is about.

C is intended to be useful, of course, which is why the standard (the
set of postulates from which we work) is designed to be both
implementable (by compiler writers) and usable (by programmers).

(If I were to concede that C is a religion, we'd merely being doing
the equivalent of asking people to discuss their blasphemies *outside*
the church doors so they don't interrupt the service. But I make no
such concession.)

 

[Keith Thompson]

Good point. This is just my experience that says me: "I have never seen a C
compiler which generated different symbols for void main() and for int
main()". And so in my mind it's not a big deal which defenition to use.

The advantage of staying within the limits defined by the standard
whenever possible is that you don't have to depend on your own
experience. If "void main()" has always worked for you in the past,
it could break tomorrow, and if you complain to your compiler vendor,
all he has to do is point to the standard. If you use "int main()"
and your program breaks, either something else is responsible for it
or you've found a compiler bug that the vendor had better fix if he
wants any repeat business.

If you would call ANSI/ISO C standard as "Bible"...

Only jokingly.

The standard is a contract between implementers and programmers. It's
binding only on those who choose to accept it (or who are required to
do so by, say, their employers). There's no legal penalty for writing
a non-conforming compiler or a non-conforming program, but there are
real benefits to conformance. In this newsgroup, we usually take that
as given rather than continually re-explaining *why* it's good to have
a standard.

Is my English so bad?

Not at all, and if I had stopped to realize that you're probably not a
native speaker of English, I would have phrased that differently. (It
was also a reference to a line from the movie "The Princess Bride".)

 

[Chris Croughton]

Good point. This is just my experience that says me: "I have never seen a C
compiler which generated different symbols for void main() and for int
main()". And so in my mind it's not a big deal which defenition to use.

It's not necessarily different symbols, it could be different code
generated. For instance, it might insist on return values being passed
back on the stack, so that for a function returning int it would do a
POP to get the return value but not for a void function -- if your void
main doesn't put that value on the stack the calling routine will try to
pop something which isn't there, possibly causing a system crash.

If you would call ANSI/ISO C standard as "Bible"...

I don't. I regard it the same way as a Health and Safety handbook -- if
you do things the way it says then you will be safe. If you don't,
you are on your own and better be very certain why you are doing it in a
different way. Not just "it saves typing a line".

Is my English so bad?

Not at all, it's better than most of the people who post to Usenet who
claim to be native English speakers (most of the errors you make look
like typos rather than lack of knowledge of English, and I make enough
of those that I can't criticise that!). However, native speakers of
English don't always understand the words they use properly either or
they use them in ways they weren't supposed to mean (especially
politicians and journalists -- you seem too sensible to be either of
those <g>) and "religious" is one of those over-used and wrongly used
words. So is "Bible", the word does literally mean just "book" but with
capital letter at start it refers to a specific book and shouldn't be
used casually to mean "any book I respect and follow" (indeed, the
Christian Bible would be madness to follow as literally as we do the C
standard!).

Chris C

 

[Richard Bos]

I'm going to say this briefly and hope that the more intelligent readers
can fill in the blanks and not worry about the lack of all the lawyerly
bells and whistles that are ordinarily necessary.

I could put that even more briefly, but in the interest of civility I
won't.

The content of this ng is religious in the sense that it has to do with the
contents of a document

The law is religious? Literature? Seems to me that you should go see a
real church from the inside, to know what you're talking about.

Richard

 

[Chris Dollin]

The content of this ng is religious in the sense that it has to do with
the contents of a document - and, by extension, the goings on of the minds
of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*). Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.

The document says that there is no obligation on the part of an implementor
to make `void main` "work" (whatever that means), so don't do it if you
want predictable results. This is not religion: it's contract law. Or
engineering.

Suppose, for example, that your local by-laws prevent you from running
a business from your home. You are free to experiment with running such
a business. You may even make a profit. However, should TPTB discover your
activities, you may experience undefined behaviour.

Suppose that you're building some circuit, and a 10-ohm resistance is
required [1]. You use a 7-ohm resistor, since your daughter used the last
10-ohm resistor yesterday as an earring, and you know from experience
that this "works". When this particular 7-ohm beast turns out to be at
the low end of the range and the smoke gets out and the circuit fails
in an embarassing (perhaps dangerous) fashion ...

I think the point is not so much that any particular thing (such as that
which is currently under discussion) is a matter of religion as that the
entire scope and charter of this ng is much more in line with a religious
framework than that of a scientific one.

Computer science isn't a science; we already knew this.

Now, if you want /religious/ arguments, indentation, tab-size, global
variables, ncspellingOfVariableNames, i++ vs ++i vs i += 1, for(; vs
while(1), &co, all seem to be waiting, fuel-soaked and steaming gently,
in the wings.

[1] All figures made up.

 

[Emmanuel Delahaye]

Anton Petrusevich wrote on 08/08/05 :

What if I do not care about the return value of the program?

Who is 'I' ? AFAIK, 'I' is the system. You have no control on it.
Returning an undefined value to the system invokes an undefined
behaviour. Period.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Anton Petrusevich]

Who is 'I' ? AFAIK, 'I' is the system. You have no control on it.
Returning an undefined value to the system invokes an undefined
behaviour. Period.

It (the behaviour) can be perfectly defined for some particular system. The
system just returns (undefined) & 255 to the process which executed the
program. And then this process reads that (undefined) octet and happily
throws it away. I am not interested in this discussion anymore.

 

[Chris Dollin]

What if I do not care about the return value of the program? Or better,
what if I _do_ care but use exit(0)?

The Standard doesn't say what a `void main` might mean, so using it
isn't portable. It doesn't matter whether or not you call `exit`,
as far as I can tell.

 

[Emmanuel Delahaye]

Anton Petrusevich wrote on 08/08/05 :

I don't get it. I thought, and I still continue to think, that "undefined
behaviour" means just that: when the behaviour is undefined. If the
behaviour is dependent on some defined thing (platform) then it's
"defined". You (or I) just need to know the platform. Of course, there's no
such (defined) thing as "platform" in C standard, so they say "undefined
behaviour". "int main()" is a tough religion, isn't it?

No matter what you think. Just stick to the facts. The C standard
defines a number of behaviours. Some others are clearly under the
responsability of the implementation (implementation-dependent). The
rest is simply 'undefined'. It's a fact. Period. There is nothing
really to argue about it.

What is undefined can do anything. The result is not predictable and
not reproducable. It's a bug. Period.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

 

[Keith Thompson]

Anton Petrusevich wrote on 08/08/05 :

No matter what you think. Just stick to the facts. The C standard
defines a number of behaviours. Some others are clearly under the
responsability of the implementation (implementation-dependent). The
rest is simply 'undefined'. It's a fact. Period. There is nothing
really to argue about it.

What is undefined can do anything. The result is not predictable and
not reproducable. It's a bug. Period.

To clarify (and disagree slightly) ...

The phrase "undefined behavior", as used in this newsgroup, refers to
behavior that is not defined by the C standard. Such behavior might
or might not be defined by something else (the hardware, some
secondary standard, or whatever).

As far as the C standard is concerned, code that exhibits undefined
behavior can do anything; we jokingly talk about it making demons fly
out your nose. This doesn't mean that nasal demons are a real
possibility, just that if demons *do* fly out your nose it doesn't
mean the C implementation is non-conforming.

In some cases, it can make sense to do something that's UB as far as
the C standard is concerned, *if* you have some other guarantee that
it will behave as you expect. You just need to be aware that the code
is non-portable -- and you should probably spend some time thinking
about whether there's a portable way to do it (sometimes there isn't).

For example, a union of a double and a struct containing carefully
defined bitfields can be a good way to get at the components of a
floating-point variable (sign, exponent, mantissa) -- but only at the
risk of having the code break when you port it, or when you upgrade to
a new compiler, or when your sysadmin upgrades your compiler behind
your back.

In other cases, undefined behavior is truly dangerous with no
corresponding benefit. For example, gets() cannot be used safely; it
will overflow your input buffer at the whim of the user.

It can also be useful to understand the *likely* consequences of
particular forms of undefined behavior, in general or for a particular
platform. An example I've mentioned here before is void main(); it
invokes undefined behavior, and it should be corrected, but if your
program is blowing up on line 137 you should also look elsewhere for
the cause.