HeathField Strange Ideas!

[Eric Sosman]

Is there a C90 conforming mode? If so, IMHO, you should have assigned
the '-ansic' switch to that instead of C99 mode, since most programmers
think of the language defined by the C90 standard, when they encounter the
acronym ANSI.

If the extensions all involve the use of reserved
identifiers like _stdcall, conformance to "ANSI" is
not threatened.

 

[Al Balmer]

On Sat, 25 Aug 2007 13:22:49 +0100, Malcolm McLean wrote:

The vast majority means "much more than 50%". I don't think that
many integers are used as indexes. I was only showing uses which,
IMO, cover almost or more than 50% of integers used.
(Of course, if you say that the integers in
while ((ch = getchar()) != EOF) putchar(ch);
are used to index a character table, you will never see my point.
Anyway, if nobody ever thought of having getchar() return a size_t
there are good reasons, don't you think so?)

It doesn't matter. We talk about C programming here, not statistics.
If Mr. McLean doesn't like the C language, surely he can find
something else among the thousands of languages that have been
invented. Perhaps there's even one whose types are based on the
frequency with which they're needed.

 

[Keith Thompson]

lcc-win32 supports C99. If you do not want any extra features you
call it with

lcc -ansic foo.c

Note that with -ansic there is still support for
non standard constructs like _stdcall. This is to
allow people that use the -ansic option to be able to
compile windows programs.

You've said that lcc-win32 does not support all C99 features. IMHO
you should have mentioned that rather than claiming without
qualification that "lcc-win32 supports C99".

Any conforming C90 compiler supports a large subset of C99. lcc-win32
apparently supports a somewhat larger subset of C99.

You might consider suporting a *strict* ISO C mode, in which
extensions (even ones allowed by the standard) are disabled. This
would make it easier for users to determine whether the code they're
compiling is potentially portable to other implementations.

 

[Malcolm McLean]

Earlier, when pete asked if you thought you had persuaded anyone at
all, you said:

| Ben Bacarisse has I think got the idea. That's not to say he agrees
| with me, but he sees the implications of allowing size_t into code,
| and understands why I resist.

This mealy-mouthed form of words is deliberately designed to suggest
that I agree whilst saying that I do not. You could have said "I
think Ben agrees" -- and waited to be told that I do not -- or you
could have said "No, I have persuaded no one" and had, at least, the
benefit of accuracy. Instead you tried to write both at once.

I don't think there's anything mealy mouthed about that. Not all questions
can be answered yes/no. In fact if someone demands "a simple yes or a simple
no" there's usually something wrong with the question in some way.

 

[Philip Potter]

If the extensions all involve the use of reserved
identifiers like _stdcall, conformance to "ANSI" is
not threatened.

AIUI _stdcall isn't reserved, only __stdcall is. (And _Stdcall, though I've
never seen that used.)

 

[Michal Nazarewicz]

If the standards in some way do restrict the C language, I would
suggest that it be more usefull to correct the standards, than to
correct the C language in such a manner to make it less portable. Who
does this guy think he is?

Firstly, the standard does not restrict the language -- you can have
a routine to access keyboard in given implementation. Standard only
specifies the minimal requirements implementation have to fulfil.

In fact adding additional requirements would make language less
portable. For instance how do you want to read a key from keyboard on
a microprocessor which has no keyboard is attached to? Or clear a screen
where no screen is available?

If you want you can go complaining to OS vendors that they have no
common standard for controlling keyboard or screen. You can go to
Microsoft and ask why Windows does not implement POSIX standard or you
can go to any Unix/Unix-like OS vendor and ask why they have different
functions then Windows have.

 

[Michal Nazarewicz]

size_t is not just used for sizes of memory, it is also used to count
arrays. If it was used perfectly consistently then int would fade
away, because only a few integers are used as natural numbers, the
vast majority count or index things, or are used in intermediate
calculations to derive indexes.

Not true. If you thing about abstract algorithms then you may be
right, however, you may not forget that abstract algorithms are useless
if you do not store any data and data in many cases can be integers,
ie. bank account balance, geographic coordinates where positive numbers
are East/North and negative West/South, temperatures in Scotland in
January 2006...

However size_t will not be used consistently for everything that
counts or indexes item in memory. People will still not infrequently
use int. So the result is a mishmash of integer types.

With this way of thinking you should also remove "const" from
C language. I have seen quit a few C projects which almost never use it
(ie. functions which analyse strings take "char *" as an argument
instead of "const char *"). I believe that there are more things that
people are inconsistent in using.

So you end up writing little routines to convert arrays of int to
size_t s and back again, even though they are all the same underlying
bit representation, all because Fred wants a list of ints and Jim
a list of size_ts.

If Fred wants a list of ints and Jim a list of size_ts then one of them
thinks that this list is something different then it in fact is. If
both Fred and Jim were consistent they would choose single type to use
for list's elements.

 

[Ben Bacarisse]

AIUI _stdcall isn't reserved, only __stdcall is. (And _Stdcall, though
I've never seen that used.)

_stdcall is reserved as an identifier at file scope (both as an
ordinary identifier and as a tag name). The upshot is that an
implementation can do what it likes with _stdcall provided that it
doses not interfere with the name being used as a macro or as an id
*not* at file scope.

As you say, __stdcall and _Stdcall are reserved for all uses.

 

[Eric Sosman]

AIUI _stdcall isn't reserved, only __stdcall is. (And _Stdcall, though
I've never seen that used.)

Thanks for the correction. It turns out _stdcall is
reserved, but only at file scope. The programmer must not
use _stdcall as an identifier outside a function, but may
use it in a function argument list or inside a function's body.
Or, turning things around, the compiler can recognize _stdcall
as something special if it appears at file scope, but must
not give it special treatment elsewhere.

 

[jacob navia]

Thanks for the correction. It turns out _stdcall is
reserved, but only at file scope. The programmer must not
use _stdcall as an identifier outside a function, but may
use it in a function argument list or inside a function's body.
Or, turning things around, the compiler can recognize _stdcall
as something special if it appears at file scope, but must
not give it special treatment elsewhere.

This compiles under lcc-win32:
void _stdcall fn(void)
{
int _stdcall=0;
}

The semantics are as you would expect.
MSVC produces:
tstdcall.c(3) : error C2059: syntax error : ';'

 

[jacob navia]

_stdcall is reserved as an identifier at file scope (both as an
ordinary identifier and as a tag name). The upshot is that an
implementation can do what it likes with _stdcall provided that it
doses not interfere with the name being used as a macro or as an id
*not* at file scope.

As you say, __stdcall and _Stdcall are reserved for all uses.

This compiles under lcc-win32:
void _stdcall fn(void)
{
int _stdcall=0;
}

The semantics are as you would expect.
MSVC produces:
tstdcall.c(3) : error C2059: syntax error : ';'

jacob

 

[Christopher Benson-Manica]

I don't think there's anything mealy mouthed about that. Not all questions
can be answered yes/no. In fact if someone demands "a simple yes or a simple
no" there's usually something wrong with the question in some way.

Is the behavior of the following program defined or not?

int main(void) {
return 0;
}

How about this one?

int main(void) {
printf("Yes or no?\n");
return 0;
}

Would you care to explain what is wrong with these questions? Or, for
that matter, with "Does X agree with Y's contentions or not?"

 

[Walter Roberson]

Is the behavior of the following program defined or not?

int main(void) {
return 0;
}

The behaviour is defined until the return statement is processed,
but no further. The return value of 0 is -intended- to specify
a "successful" execution, but C leaves undefined what that
actually means. In some OS's, the "succesful" return
of this do-nothing program could, for example, lock all of a
city's traffic lights on "flashing red" -- as, in context, -any-
return from the program might be unusual or unexpected
or supposedly not possible and "flashing red" might be the
hardware fail-safe.

But if you were to define what the OS will do when it gets
a successful return, then we could tell you what the effect
of running the program would be. So "it depends".

 

[Christopher Benson-Manica]

The behaviour is defined until the return statement is processed,
but no further.

Aside from the fact that the question (apparently) ought to have been
"Is the following program strictly conforming or not?", it seems
rather useless to note that the behavior of the program is not defined
once it has ceased executing. The question IMO clearly specifies
interest in what the *program* does, and not what the OS might do
after a "successful" program execution.

 

[Kenneth Brody]

Eric Sosman wrote:
[...]

When pressed, Jacob admits that his compiler supports
"C with extras" in addition to (he says) Standard C. He
does not claim that operator overloading and String and the
rest are part of C -- and that's attributable, at least in
part, to the existence of the Standard. In the B.O.D. people
*did* just add new gadgets to their implementations and call
the result "C," and since there was no arbiter to say otherwise,
they got away with it.

[...]

Well, what is the definition of a "C compiler"? I assume that it
means it will properly compile any conforming C program. I do not
assume that it means it will fail to compile any and all non-
conforming programs, nor that it contains no extensions to the
Standard.

My *nix boxes have perfectly good C compilers on them, even though
I can open() files and communicate via TCP/IP sockets. I believe
that the man pages on these "extra" features don't state that they
are part of ANSI C, but rather that they are part of some other
standard (if appropriate), or that they are an extension from some
other source.

I don't believe that they need to be called "C (with extras)
compilers".

On the other hand, I see the OP has not posted any replies to this
thread as of yet, over 2-1/2 days later.

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

 

[Kelsey Bjarnason]

[snips]

size_t is not just used for sizes of memory, it is also used to count
arrays. If it was used perfectly consistently then int would fade away,

Size_t is, last I checked, an unsigned integer type. This would be most
improper for anything involving negative values:

size_t x = -2;
size_t y = -3;

What's the result of x + y? Is it -5? Not here it ain't.

Next.

 

[Kelsey Bjarnason]

[snips]

[2] Because sizeof returns it and many library functions require it.
Even if you write 'int len = sizeof x;' you are using size_t -- in a
way that introduces a possible portability issue depending on what
size x may be.

That's the problem with size_t.
If we were forced to use size_t all the time

Then code would break, as demonstrated elsewhere.

the objection would be
merely to its ugly spelling and unsignedness.

You often need to get the -3rd element of a buffer, do you?

As it is it a poison that
propagates through code, destroying the compatibility of functions with
each other

Odd, I don't see this happening. I also note you don't demonstrate an
actual case of it.

, because most people will still e int where strictly it
should be a size_t.

Who is "most people"? Most C programmers I'm aware of actually use size_t
when dealing with buffers and the like, as size_t is the proper type.
The only one, in fact, I see regularly using int - and thus producing
broken code - is *you*.

 

[Richard Heathfield]

Kelsey Bjarnason said:

[snips]

size_t is not just used for sizes of memory, it is also used to count
arrays. If it was used perfectly consistently then int would fade
away,

Size_t is, last I checked, an unsigned integer type. This would be
most improper for anything involving negative values:

size_t x = -2;
size_t y = -3;

What's the result of x + y? Is it -5? Not here it ain't.

Next.

Next is:

#include <stdio.h>

int main(void)
{
size_t x = -2;
size_t y = -3;
size_t z = -5;
if(x + y == z)
{
puts("Here, however, it is. ");
}
else
{
puts("Here neither.");
}
return 0;
}

 

[Malcolm McLean]

I don't think there's anything mealy mouthed about that. Not all
questions
can be answered yes/no. In fact if someone demands "a simple yes or a
simple no" there's usually something wrong with the question in some way.

Is the behavior of the following program defined or not?

int main(void) {
return 0;
}

How about this one?

int main(void) {
printf("Yes or no?\n");
return 0;
}

Would you care to explain what is wrong with these questions? Or, for
that matter, with "Does X agree with Y's contentions or not?"

usually
^^^^^
You can create a question which has a "simple yes or a simple no" answer.
Those who demand "a simple yes or a simple no" as an answer usually have
defective questions, like "is C++ better than C, yes or no?". Of course you
can't answer that, it depends on the problem you are trying to solve with
the program.

 

[user923005]

They are just pedants. Do not worry. Not everyone is like them here.

Main Entry: ped·ant
Pronunciation: 'pe-d&nt
Function: noun
Etymology: Middle French, from Italian pedante
1 obsolete : a male schoolteacher
2 a : one who makes a show of knowledge b : one who is unimaginative
or who unduly emphasizes minutiae in the presentation or use of
knowledge c : a formalist or precisionist in teaching

Concering meaning c), I will have to agree with you. Of course in a
technical field like computer programming, getting things precisely
right is very important.

He think he is the pope, and many people here believe that, maybe
because some people *need* a pope to rely on. Much easier than using
the brain...

He's not the Pop, there's only one Dan Pop. When Dan Pop isn't
around, I still have my copy of the ANSI/ISO standard (which is almost
as good).

It is a good book, with some bugs as any other book, but in
general useful.

To the casual reader of this thread:
You will find the defenders of Richard Heathfield are those that
understand the C language and the detractors are generally
nincompoops.
IMO-YMMV.