Automatically generate variables

[santosh]

Nonsense. It is C. It's not strictly conforming, it won't work
almost anywhere, it's rather useless, it's off-topic here, all this
was in details explained in another reply to JN post. But it is C,
where "C" means "C language as defined by the ISO standard".

But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard. If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.

 

[jacob navia]

santosh a écrit :

But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard. If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.

This means that there is no single serious program besides hello world
ones that is written in C.

OK?

Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.

There are then NO PROGRAMS WRITTEN IN C.

Satisfied?

 

[Flash Gordon]

jacob navia wrote, On 17/02/07 19:08:

santosh a écrit :


This means that there is no single serious program besides hello world
ones that is written in C.

OK?

Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.

There are then NO PROGRAMS WRITTEN IN C.

Satisfied?

You've posted this before when people have pointed out that some things
are not C but extensions. The answer is still the same that some
programs can be written completely in standard C and vast amount more
can have 95% written in standard C with the remaining 5% nicely isolated
and written in whatever system specific method is appropriate.

 

[Yevgen Muntyan]

But the ISO standard doesn't define the windows.h header or the
functions LoadLibrary or GetProcAddress. It uses the syntax and
semantics as defined in the standard, but uses various extensions not
defined in the standard.

This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?

I personally don't have that wider definition, and I don't think
anyone could come up with something sensible here. And it's the
reason why *on-topic* here are only strictly conforming programs.
But there is more to C than programs using only standard features.

For instance, a C program which uses POSIX regex to work with
some strings, or a program which uses windows API to print list of
processes, are C programs as long as they don't use some fancy
non-C syntax or mechanics (insert "semantics" here).

If one or more of these extensions change the
standard syntax and semantics of C, then it's debatable if the
resulting code can even be called as C. That's why GNU C is called as
GNU C and not C.

I'd say "GNU C" is the same nonsense as "C/C++". There is one C
language, and there are extensions to it; "C with GNU extensions" sounds
better here. If you need gcc to compile a program, then it's not
a "C program as defined by the C standard", it's a program written
in GCC dialect of C or whatever you call it. But if any working
(QoI thing here) compiler on given platform (one more non-standard
thing, you got to accept that <windows.h> is only for windows) can
compile it without any fancy compatibility switches, then it's C. It's
just an empiric test of course, without 100% success guarantee. But
then, one can't prove that given program of reasonable complexity is
strictly-conforming either (I guess one could say he can get all
conforming implementations in the world and simply check, according
to the definition, I'd love to see that).

Anyway, answer to "C or not C" certainly should not involve sympathy or
antipathy to Jacob Navia. Saying "beep beep not C hahaha because I don't
like you" is total nonsense. Off-topic, sure. But C. If one says
that silly JN's program isn't C, he says that the great deal of C
programs (like all the C programs which work on your computer, except
maybe one) suddenly stop being C programs. And that's nonsense.
And it's not only about JN's program of course, elsewhere people already
told that C means in comp.lang.c something different than in the
rest of the world.

Yevgen

 

[Yevgen Muntyan]

jacob navia wrote, On 17/02/07 19:08:

You've posted this before when people have pointed out that some things
are not C but extensions. The answer is still the same that some
programs can be written completely in standard C and vast amount more
can have 95% written in standard C with the remaining 5% nicely isolated
and written in whatever system specific method is appropriate.

Looks like there are two ways to apply C standard in real life. One is
to call C programs (not necessarily strictly conforming) C programs;
another one is to claim that something *can* be done in some way. Note
that the standard doesn't know what it means 95% is C and 5% isn't.
You pollute your program with "1%" of non-C and it stops being C,
the whole thing is no longer a C program (namely what you call a C
program). And it's certainly true that vast majority of real C programs
installed on computers are not written that way, 95% here and 5%
isolated there. Jacob isn't right here of course, there are strictly
conforming C programs, sure. But his statement (the conditional one,
the "if that's not C then there are no C programs") is far closer
to reality and truth than your "answer", that "vast amount more *can*
have .." (emphasis mine).

I do agree that Jacob is one of persons who make it harder to talk
about real life C applications here, but if one wants to shut him up,
he can choose lot of other things, without the need to make this
newsgroup like bunch of jerks who pretend real programs are not what
they actually are.

Yevgen

 

[santosh]

This is true, but we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former
is what I call nonsense, simply because it's too restrictive - if
one accepts such definition of a "C program", then all those C
programmers out there are writing programs in some fancy language
which is not C, and all those C programs out there are not C
programs. Then, I think the standard exists to make people able
to write C programs using extensions. And it uses term "strictly
conforming" exactly to distinguish programs which are completely
described and programs which use extensions but are still C programs,
but to not restrict itself only to those strictly conforming
programs. The syntax and semantics of "a C program" have very big
value, what would be the point of having the standard which simply
stops working as soon as non-standard header is used?

<rest snipped>

I can see your reasoning.

The imaginary boundary which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred. The standard fully defines conforming C programs. In
addition it allows implementation specific decisions for various
aspects and extensions as well. Certainly the code posted by jacob
navia qualifies as C code. The issue is what we exactly mean by term C
code. If we mean "the language as defined by the C standard", (which
is what you wrote earlier), then does his code snippet qualify as C
code? I think so.

But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so. What
makes one extension reasonable and another not, from the POV of being
compatible with C?

Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion, something I'm not happy about.

 

[Richard Heathfield]

santosh said:

The imaginary boundary

....is not imaginary, and is not a boundary.

which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred.

Yes, it's more like a beard than a boundary. Does a man with one hair on
his chin have a beard? Clearly not. Does a man with ten thousand hairs
on his chin have a beard? Yes, and to spare! So where is the dividing
line? If we say a man with N hairs on his chin has no beard, but a man
with N + 1 hairs /does/ have a beard, people would rightly laugh. And
yet some men have beards, and others don't.

The standard fully defines conforming C programs.

Perhaps, but not their behaviour. It only says that a conforming C
program is one that is acceptable to a conforming implementation.

Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion, something I'm not happy about.

Yes, the concept of "strictly conforming" is too strong to be useful,
and the concept of "conforming" too weak. In this newsgroup, the
concept of "comp.lang.c-conforming" has proved itself to be far more
effective.

 

[jacob navia]

Yevgen Muntyan a écrit :

I do agree that Jacob is one of persons who make it harder to talk
about real life C applications here, but if one wants to shut him up,
he can choose lot of other things, without the need to make this
newsgroup like bunch of jerks who pretend real programs are not what
they actually are.

Yevgen

Look Yevgen, I can't parse that sentence. Maybe shorter sentences would do.

What I wanted to demonstrate with my snippet is basically:
1) You can use a C program to generate a C source file.
2) You can use the C compiler to compile it
3) You can use the dynamic loader to load it into memory
4) You can get a function pointer from the loaded file
and execute it.

This is possible in a wide variety of systems, from Unix, to
Windows, to many embedded systems. It is called a JIT, a
Just In Time compiler. Obviously how do you implement those
steps is system specific, and will change slightly from
system to system.

Instead of going into the question at hand (generating C
programs dynamically) we delve into boring stuff about
this being C or not. This is ridiculous and hinders any
discussion about real programs.

jacob

P.S. I do see the danger of discussiong very system specific
stuff, but the OTHER danger, not discussing anything at all but
the restricted subset of C proposed by some people here is even
worst!

 

[Ian Collins]

But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so. What
makes one extension reasonable and another not, from the POV of being
compatible with C?

One has to draw the distinction between extensions to the language (the
&& gcc extension and operator overloading) and platform specific
libraries. It is a fairly straightforward exercise for a developer to
implement a set of functions defined in a library (say Posix file
handling or BSD style sockets), but not to implement extensions to the
language. Which makes the former portable and the latter not.

Anything which conforms to the language defined in the current C
standard is a C program, which includes programs that include
non-standard headers.

 

[Yevgen Muntyan]

<rest snipped>

I can see your reasoning.

The imaginary boundary which divides a peice of code from being
reasonably called as C from being in a C-like language is undefined
and blurred. The standard fully defines conforming C programs.

No it doesn't, it fully defines strictly conforming programs,
the ones which in particular do not contain code like

#include "foo.h"

"Just" conforming is no good, C++ programs seem to be conforming
because gcc accepts them, and gcc is a conforming implementation
(GNU compiler collection, that is, not the binary called 'gcc').

In
addition it allows implementation specific decisions for various
aspects and extensions as well. Certainly the code posted by jacob
navia qualifies as C code. The issue is what we exactly mean by term C
code. If we mean "the language as defined by the C standard", (which
is what you wrote earlier), then does his code snippet qualify as C
code? I think so.

Yes, I do think so too.

But what about more fundamental extensions like the && gcc extension
discussed in another thread or the various operator overloading
features implemented by the lcc-win32 compiler? Can code that use such
"radical" extensions still be called as C? I don't think so.

I agree here too.

What
makes one extension reasonable and another not, from the POV of being
compatible with C?

And I don't know the answer for this. And as I said, I don't think
one can provide sensible answer which would not involve what one
feels as opposed to what exactly is said in some definition.

Unless we take the strict approach of adhering to what the standard
specifies and allows, we seem to get into a lot of "gray areas" about
what is, and is not, C. It seems to ultimately come down to personal
opinion,

True. But it's not bad. It seems to me people generally agree on
what's C and what's not C (unless it's an argument in comp.lang.c).
And that's what really matters.

something I'm not happy about.

Sure, it would be easier if the standard said "this is C, and the
rest isn't C and I don't care about that", but then the standard
would be useless. So we have what we have. I believe it's called
"trade off" in English.

Yevgen

 

[CBFalconer]

.... snip ...

I do agree that Jacob is one of persons who make it harder to talk
about real life C applications here, but if one wants to shut him
up, he can choose lot of other things, without the need to make
this newsgroup like bunch of jerks who pretend real programs are
not what they actually are.

He goes along for a while being fairly reasonable, and then breaks
out with one of his diatribes. The point here is that we don't
want to discuss the myriad extensions and libraries that are
available for C, but we do want to discuss things that have a firm
basis, such as an ISO standard.

Jacob has a whole mainstream newsgroup in which to espouse his
extensions and theories, i.e. comp.compilers.lcc. However he
insists on disturbing c.l.c with off-topic material, and in the
process is making himself look ridiculous, and generally annoying
the users. The result is that even if he says something
worthwhile, it is highly likely to be ignored or picked to pieces.
If he co-operated with the group, he would get more co-operation
from the group. It will probably take a year or two of
co-operation on his part before he will be taken seriously by most
regulars here.

Jacob is not alone with this problem. Note that such things as
regexs can be built entirely withing standard C - all that is
required for discussion of usage is to include the appropriate code
in the article, or at least a proper description of it with a link
to the ISO standard source.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Keith Thompson]

What I wanted to demonstrate with my snippet is basically:
1) You can use a C program to generate a C source file.

Agreed. Strictly speaking, I'm not sure that the specification for
what must be accepted as a C source file necessarily exactly matches
the representation of a text file generated by stdio calls, but I'll
ignore that; if nothing else, a format translation should be
straightforward. (This isn't entirely theoretical; consider a
cross-compiler where the host and target systems have different text
file representations.)

2) You can use the C compiler to compile it

Sure, if you have a C compiler. Not all systems do.

3) You can use the dynamic loader to load it into memory

That's extremely system-specific.

4) You can get a function pointer from the loaded file
and execute it.

Likewise, that's extremely system-specific.

The solution you propose is so system-specific as to be unworkable in
general. Consider MS Windows systems, for example. There are several
free C implementations for MS windows, and several for which you have
to pay money. There is no one compiler that you can assume will exist
on any particular system. If you distributed a Windows program that
depended for its operation on the mechanism you describe, there would
be no way to make it work in general (unless you distribute a C
compiler along with it). And that's just one operating system; a
general solution is quite impossible (short of a huge nest of
#ifdef's).

This is possible in a wide variety of systems, from Unix, to
Windows, to many embedded systems. It is called a JIT, a
Just In Time compiler. Obviously how do you implement those
steps is system specific, and will change slightly from
system to system.

How many embedded systems have C compilers available *on the target
system*? And I don't believe that the implementation wil change
"slightly" from system to system; there is no standard for this kind
of thing.

I'm not aware of anyone who's actually implemented what you suggest
even in a manner that will work on both Unix and Windows, systems
which are far more similar to each other than a number of other
systems out there.

And, as I recall, the solution you proposed, even assuming it can be
made to work, wasn't even appropriate to the OP's problem. All he
really needed was an array.

[snip]

 

[Flash Gordon]

jacob navia wrote, On 17/02/07 22:07:

Yevgen Muntyan a écrit :

Look Yevgen, I can't parse that sentence. Maybe shorter sentences would do.

What I wanted to demonstrate with my snippet is basically:
1) You can use a C program to generate a C source file.
Yes.

2) You can use the C compiler to compile it

What makes you think a C compiler is installed on the majority of systems?

3) You can use the dynamic loader to load it into memory

What makes you think a dynamic loader is part of C?

4) You can get a function pointer from the loaded file
and execute it.

This also is not part of standard C.

This is possible in a wide variety of systems, from Unix, to

Not if the compiler is not installed.

Windows,

Windows does not have a compiler installed by default and probably most
Windows systems do not have one.

> to many embedded systems.

I've yet to use or develop for an embedded system that came with a C
compiler installed on it. For a start the compilers for most embedded
systems are build to run on completely different hardware.

It is called a JIT, a
Just In Time compiler. Obviously how do you implement those
steps is system specific, and will change slightly from
system to system.

So you provide a solution where only the most trivial step is C and the
rest is system specific and would require installing additional software
on the target system (that may not be available for it) and call it a C
solution?

Instead of going into the question at hand (generating C
programs dynamically) we delve into boring stuff about
this being C or not. This is ridiculous and hinders any
discussion about real programs.

It is not C.

jacob

P.S. I do see the danger of discussiong very system specific
stuff,

Such as what you posted? Care to give me a solution that will run on my
customers server where they have a policy of not having a C compiler
installed on the server?

> but the OTHER danger, not discussing anything at all but
the restricted subset of C proposed by some people here is even
worst!

It is not a restricted subset unless you consider the entire language to
be a restricted subset of itself. Anyway there is plenty to discus.

 

[Mark McIntyre]

On Sat, 17 Feb 2007 20:08:57 +0100, in comp.lang.c , jacob navia

(of the idea that extensions to C are not part of the language)

This means that there is no single serious program besides hello world
ones that is written in C.

Must we do this *again*?

OK?

No, no a thousand times no.

Just because you, with you apparently limited experience , have never
written a utility programme, filter etc, does not mean that such do
not exist and are not serious.

Neither the linux kernel, nor all the network programs, nor any GUI
program, nor any library that uses graphics, networking, threads,
exception handling, nor the dynamic loader, nor any program that uses
a directory structure (file directories aren't defined in standard
C) nor all the embedded systems that use myriads of extensions
adapted to each circuit board, etc.

Correct - none of that is ISO standard C. It all requires
platform-specific extensions.

There are then NO PROGRAMS WRITTEN IN C.

Wrong.

Satisfied?

Only that you're being idiotic again.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

One has to draw the distinction between extensions to the language (the
&& gcc extension and operator overloading) and platform specific
libraries. It is a fairly straightforward exercise for a developer to
implement a set of functions defined in a library

I'm not sure I'd entirely agree with that. It'd be fairly hard to
implement the Win32 libraries on most embedded systems, I suspect.
Unless "implement" includes returining a noop...

Anything which conforms to the language defined in the current C
standard is a C program, which includes programs that include
non-standard headers.

Inasmuch as Geordie is still English. Which is to say not with respect
to passing an exam or making yourself understood in Arizona or
Auchtermuchty.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Mark McIntyre said:

On Sat, 17 Feb 2007 20:08:57 +0100, in comp.lang.c , jacob navia


Correct - none of that is ISO standard C. It all requires
platform-specific extensions.

Well, most of it does, but I've written plenty of graphics programs in
ISO C. Also, although C doesn't support directories, it allows you to
read information from a file, and you can certainly store file location
information in a file. I'd have thought that someone with sufficient
creative imagination to come up with a (platform-specific) LoadLibrary
hack to generate callable C functions at run-time would be able to
consider some of the possibilities inherent in C's support for files.

Wrong.

Indeed. I've written plenty of programs in straight C. Yes, I've written
plenty of programs in C-plus-extensions too, but the fact that programs
exist that are written in C-plus-extensions does not in any way imply
the non-existence of programs written in C-sans-extensions.

 

[Yevgen Muntyan]

I'm not sure I'd entirely agree with that. It'd be fairly hard to
implement the Win32 libraries on most embedded systems, I suspect.
Unless "implement" includes returining a noop...

It does, indeed. Point is that calling conventions, preprocessor magic,
syntax are all the same. If your program is

#include <windows.h>
int main (void)
{
return 0;
}

then it's a C program. If your program is

#include <magic.h>
int main (void)
{
return return 1.345e18u87;
}

then it's not.

Inasmuch as Geordie is still English. Which is to say not with respect
to passing an exam or making yourself understood in Arizona or
Auchtermuchty.

It's good that there is this English language, and nobody knows
now what really is "correct" English, but it doesn't have much
to do with C. What language is the first program posted here? Is
it C? If not, is it "you tell me what it is?". Whatever, that *is*
C even if you don't like Jacob Navia.

Yevgen

 

[CBFalconer]

.... snip ...

It does, indeed. Point is that calling conventions, preprocessor
magic, syntax are all the same. If your program is

#include <windows.h>
int main (void)
{
return 0;
}

then it's a C program. If your program is

No it isn't. If it had #include "windows.h" it would be. There is
no such header in standard C, but the user is allowed to create all
the headers he wishes elsewhere. All he has to do is provide them.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[boa]

Yevgen Muntyan wrote:
... snip ...

No it isn't. If it had #include "windows.h" it would be. There is
no such header in standard C, but the user is allowed to create all
the headers he wishes elsewhere. All he has to do is provide them.

Chapter & Verse, please ;-)

Boa

 

[Yevgen Muntyan]

Yevgen Muntyan wrote:
... snip ...

No it isn't. If it had #include "windows.h" it would be.

I'm afraid I can't understand this.

There is
no such header in standard C, but the user is allowed to create all
the headers he wishes elsewhere. All he has to do is provide them.

And? Is this program C or not? If not, what is it (just curious
what ridiculous things people can invent instead of using standard
"strictly conforming" term). And please don't tell "this is not standard
C", I didn't say that. I am saying "it is a C program".

Yevgen