<a href="https://bytes.com/topic/c/answers/601641-automatically-generate-variables">Automatically generate variables

On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
<nv******@sbcglobal.netwrote:

>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this,

There isn't - you can't define object names at runtime in C.

You could mallocate an array of objects however, and size it to
whatever size you needed. This is likely to be more useful anyway as
the chances are you will need to loop over the variables.
--
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

Feb 13 '07 #6

Nate wrote:

Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...

int i;

for(i = 1; i < 4; i++){

int variable....

}

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

Thanks in advance,

-Nate

#include <stdio.h>
int main(void)
{
FILE *f = fopen("variables.c","w");
for (int i=0; i<100; i++) {
fprintf(f,"int variable%d\n",i);
}
fclose(f);
}

Feb 13 '07 #7

Kenny McCormack

In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>Nate wrote:
>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...

int i;

for(i = 1; i < 4; i++){

int variable....

}

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

Thanks in advance,

-Nate

#include <stdio.h>
int main(void)
{
FILE *f = fopen("variables.c","w");
for (int i=0; i<100; i++) {
fprintf(f,"int variable%d\n",i);
}
fclose(f);
}

You need to finish what you started. IOW, you forgot to mention:
1) And then compile variables.c as a shared library
2) And then dlopen that library
3) And then enjoy your new symbols

All OT, blah, blah, blah, of course.

Feb 13 '07 #8

Mark McIntyre wrote:

On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
<nv******@sbcglobal.netwrote:

>>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this,

There isn't - you can't define object names at runtime in C.

Wrong

#include <stdio.h>
#include <windows.h>
int main(void)
{
FILE *f = fopen("dynamic.c","w");
void (*fn)(void);
void *ptr;

// 1 Define some structure for instance
fprintf(f,"struct dynamicobject { char *name;int len; };\n");
// 2 Define an object of that type
fprintf(f,"struct dynamicobject var = {\"NoName\",6};\n");
// 3 Define an exported function in a shared object that returns the
// address of the created object
fprintf(f,"void * __declspec(dllexport) \n");
fprintf("GetDynamicObject(void)\n\treturn &var;}\n");
// Done Close the file
fclose(f);
// Compile it. The compiler can change of course :-)
system("lcc dynamic.c");
// Link it into a shared object
system("lcclnk -dll dynamic.obj");
// Open the shared object (dlopen under Unix)
void *h = LoadLibrary("variables.dll");
// Get the address of the created function in the shared object
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
// Call the function we just compile
ptr = fn();
// And now, ladies and gentlemen
// Here I have a pointer to a dynamically created object
}

Most of my customers buy lcc-win32 as a "Just in time compiler", that
allows them to do this much more efficiently than what is shown here

A JIT compiler is specialized in generating code dynamically. For
instance, if you are modelling molecule interaction you can develop
a special language that is task oriented, compile it to C, then
just JIT compile it into a shared object that you run on the fly.

Of course what you generate is an object, not NAMES...
In this sense the OP is completely wrong of course.

Feb 13 '07 #9

Kenny McCormack wrote:

In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>>Nate wrote:

>>>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...

int i;

for(i = 1; i < 4; i++){

int variable....

}

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

Thanks in advance,

-Nate

#include <stdio.h>
int main(void)
{
FILE *f = fopen("variables.c","w");
for (int i=0; i<100; i++) {
fprintf(f,"int variable%d\n",i);
}
fclose(f);
}

You need to finish what you started. IOW, you forgot to mention:
1) And then compile variables.c as a shared library
2) And then dlopen that library
3) And then enjoy your new symbols

All OT, blah, blah, blah, of course.

Yes, see my answer to McIntyre

Feb 13 '07 #10

Joe Estock

Christopher Benson-Manica wrote:

Joe Estock <je*****@nospamnutextonline.comwrote:

>Or the [slightly] more maintainable way:

>#define DECLARE(var, seq) var##seq

>int main(void)
{
int DECLARE(foo, 1);
int DECLARE(foo, 2);

It's more maintainable, yes, but it also rather defeats the purpose of
the whole exercise, doesn't it? If one wants int foo1 through int
foo100, what's the added benefit of invoking the macro 100 times as
opposed to simply writing the actual declarations?

Personally I would use an array of type int; I was merely condensing
your example and I missed the very important part of functionality that
was originally sought. After reviewing your original code I see that it
defeats the original intent of declaring several variables at once. I
was distracted by the vast amount of snow outside when I replied to your
original thread.

Feb 13 '07 #11

Flash Gordon

jacob navia wrote, On 13/02/07 23:25:

Mark McIntyre wrote:
>On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
<nv******@sbcglobal.netwrote:

>>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this,

There isn't - you can't define object names at runtime in C.

Wrong

No, he is correct.

#include <stdio.h>
#include <windows.h>
int main(void)
{
FILE *f = fopen("dynamic.c","w");
void (*fn)(void);
void *ptr;

// 1 Define some structure for instance
fprintf(f,"struct dynamicobject { char *name;int len; };\n");
// 2 Define an object of that type
fprintf(f,"struct dynamicobject var = {\"NoName\",6};\n");
// 3 Define an exported function in a shared object that returns the
// address of the created object
fprintf(f,"void * __declspec(dllexport) \n");

The above line would prevent the C file that is being written from
compiling on most C compilers.

fprintf("GetDynamicObject(void)\n\treturn &var;}\n");
// Done Close the file
fclose(f);
// Compile it. The compiler can change of course :-)
system("lcc dynamic.c");

Here you are using something called a "C compiler". Strangely enough it
is not actually part of C instead it is a tool used to operate on C
sources. On some systems there will not be a C compiler installed and
the user might not have permissions to install one.

// Link it into a shared object
system("lcclnk -dll dynamic.obj");

Here you are using something called a linker which is also not part of C.

// Open the shared object (dlopen under Unix)
void *h = LoadLibrary("variables.dll");

Here you are suggesting using functions that are not part of C that are
not available on all implementations. Oh, and you security systems that
prevent untrusted programs from doing untrusted things like loding
shared objects from untrusted places (i.e. anywhere the user can write to).

// Get the address of the created function in the shared object
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");

So you are casting something to a function pointer type different from
the definition of the function pointer you are assigning it to. I would
suggest you read the manuals for the compiler you are using to find out
how to enable a sensible level of warnings, but seeing as it is your
compiler I can't imagine why they would not be set already.

// Call the function we just compile
ptr = fn();

Now you are expecting to get a return value from a function that you
have told the compiler does not return anything. Did you compiler not
generate an error here? I know the standard would allow a warning, but
an error would be more appropriate.

// And now, ladies and gentlemen
// Here I have a pointer to a dynamically created object
}

Most of my customers buy lcc-win32 as a "Just in time compiler", that
allows them to do this much more efficiently than what is shown here

Well, I hope you give them something a little closer to being a C
compiler than the above code was to being C.

A JIT compiler is specialized in generating code dynamically. For
instance, if you are modelling molecule interaction you can develop
a special language that is task oriented, compile it to C, then
just JIT compile it into a shared object that you run on the fly.

Now, had you suggested the OP embed some kind of scripting language with
or without a JIT that might have been more sensible. Instead you try to
suggest that using tools at run time that are not installed on most
systems is part of C.

Of course what you generate is an object, not NAMES...
In this sense the OP is completely wrong of course.

The OP is completely wrong to look for a solution to his/her problem or
completely wrong for not being sure if it exists?

There is no mechanism provided in C to do what the OP asked. On *some*
systems you can use things outside of the C language to do the sort of
thing you are suggesting. However you are going so far that you might as
well say that the ability to run Windows Vista is part of C.
--
Flash Gordon

Feb 14 '07 #12

Christopher Benson-Manica

Joe Estock <je*****@nospamnutextonline.comwrote:

(WRT int foo1 ... int foo100)

Personally I would use an array of type int;

Well, me too, and there probably isn't a great reason for OP not to as
well. There certainly aren't a lot of alternatives, and none that are
good.

I
was distracted by the vast amount of snow outside when I replied to your
original thread.

Posting to comp.lang.c would certainly seem to beat shoveling it :-)

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

Feb 14 '07 #13

Eric Sosman

jacob navia wrote On 02/13/07 18:05,:

Nate wrote:

>>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...

int i;

for(i = 1; i < 4; i++){

int variable....

}

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

Thanks in advance,

-Nate

#include <stdio.h>
int main(void)
{
FILE *f = fopen("variables.c","w");
for (int i=0; i<100; i++) {
fprintf(f,"int variable%d\n",i);
}
fclose(f);
}

"variables.c", line 2: undefined or not a type: variable0
"variables.c", line 3: parameter not in identifier list: variable1
"variables.c", line 3: syntax error before or at: int
"variables.c", line 4: parameter not in identifier list: variable2
[...]
"variables.c", line 99: syntax error before or at: int
"variables.c", line 100: parameter not in identifier list: variable98
"variables.c", line 101: parameter not in identifier list: variable99
"variables.c", line 101: syntax error before or at: <EOF>
cc: acomp failed for variables.c

One hundred fifty-one diagnostics all told. An impressive
yield for an investment of a mere nine lines of code.

--
Er*********@sun.com

Feb 14 '07 #14

Eric Sosman a écrit :

jacob navia wrote On 02/13/07 18:05,:

>>Nate wrote:

>>>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this, but I had something
like this in mind...

int i;

for(i = 1; i < 4; i++){

int variable....

}

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

Thanks in advance,

-Nate

#include <stdio.h>
int main(void)
{
FILE *f = fopen("variables.c","w");
for (int i=0; i<100; i++) {
fprintf(f,"int variable%d\n",i);
}
fclose(f);
}

"variables.c", line 2: undefined or not a type: variable0
"variables.c", line 3: parameter not in identifier list: variable1
"variables.c", line 3: syntax error before or at: int
"variables.c", line 4: parameter not in identifier list: variable2
[...]
"variables.c", line 99: syntax error before or at: int
"variables.c", line 100: parameter not in identifier list: variable98
"variables.c", line 101: parameter not in identifier list: variable99
"variables.c", line 101: syntax error before or at: <EOF>
cc: acomp failed for variables.c

One hundred fifty-one diagnostics all told. An impressive
yield for an investment of a mere nine lines of code.

Add a semi colon at the end of the line.
fprintf(f,"int variable%d;\n",i);

Feb 14 '07 #15

Old Wolf

On Feb 14, 5:35 am, "Nate" <nverb...@sbcglobal.netwrote:

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

int variable[4];

Then access them like this:

variable[0] = 4;
variable[1] = 3;
....
variable[3] = 10;

The numbers will be 0 through to one less than the parameter
you specified in the declaration.

If you don't know how many you will need until runtime
then you can write:
int *variable = malloc( 4 * sizeof *variable );

and then access them in the same way as before.

Feb 14 '07 #16

Nate

On Feb 14, 5:02 pm, "Old Wolf" <oldw...@inspire.net.nzwrote:

On Feb 14, 5:35 am, "Nate" <nverb...@sbcglobal.netwrote:

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?

int variable[4];

Then access them like this:

variable[0] = 4;
variable[1] = 3;
...
variable[3] = 10;

The numbers will be 0 through to one less than the parameter
you specified in the declaration.

If you don't know how many you will need until runtime
then you can write:
int *variable = malloc( 4 * sizeof *variable );

and then access them in the same way as before.

OW,

This solution will work perfectly for what I'm trying to do, thank you
for your suggestion.

In fact, I will know the size needed for the array each time so it
will make the solution that much easier to implement.

Thanks again,

-Nate

Feb 15 '07 #17

santosh

Nate wrote:

On Feb 14, 5:02 pm, "Old Wolf" <oldw...@inspire.net.nzwrote:
On Feb 14, 5:35 am, "Nate" <nverb...@sbcglobal.netwrote:

For example, this loop would declare the following variables all of
type int:

variable1
variable2
variable3

Is something like this possible? Is there another way?
int variable[4];

Then access them like this:

variable[0] = 4;
variable[1] = 3;
...
variable[3] = 10;

<snip>

OW,

This solution will work perfectly for what I'm trying to do, thank you
for your suggestion.

<snip>

You could've said you wanted arrays. Your C text should have atleast a
chapter on it.

Feb 15 '07 #18

On Wed, 14 Feb 2007 00:25:45 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Mark McIntyre wrote:
>On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
<nv******@sbcglobal.netwrote:

>>>Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this,

There isn't - you can't define object names at runtime in C.

Wrong

Right.

>#include <stdio.h>
#include <windows.h>

Beep beep. This isn't C.

void *h = LoadLibrary("variables.dll");
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");

This isn't either.

But then you knew this, you just wanted to disagree with me I suspect.
--
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

Feb 17 '07 #19

Mark McIntyre wrote:

On Wed, 14 Feb 2007 00:25:45 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Mark McIntyre wrote:
>>On 13 Feb 2007 08:35:59 -0800, in comp.lang.c , "Nate"
<nv******@sbcglobal.netwrote:
Hello,

I am looking for a method to automatically declare variables in C.
I'm not sure if there is a good way to do this,

There isn't - you can't define object names at runtime in C.

Wrong

Right.

Agreed.

>#include <stdio.h>
#include <windows.h>

Beep beep. This isn't C.

> void *h = LoadLibrary("variables.dll");
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");

This isn't either.

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".

Yevgen

Feb 17 '07 #20

santosh

Yevgen Muntyan wrote:

Mark McIntyre wrote:
jacob navia wrote:
Mark McIntyre wrote:

<snip>

>There isn't - you can't define object names at runtime in C.

Wrong

#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.

void *h = LoadLibrary("variables.dll");
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
This isn't either.

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.

Feb 17 '07 #21

santosh a écrit :

Yevgen Muntyan wrote:

>>Mark McIntyre wrote:

>>>jacob navia wrote:

Mark McIntyre wrote:

<snip>

>>>>>There isn't - you can't define object names at runtime in C.

Wrong

#include <stdio.h>
#include <windows.h>

Beep beep. This isn't C.
void *h = LoadLibrary("variables.dll");
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");

This isn't either.

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.

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?

Feb 17 '07 #22

santosh wrote:

Yevgen Muntyan wrote:
>Mark McIntyre wrote:
>>jacob navia wrote:
Mark McIntyre wrote:

<snip>

>>>>There isn't - you can't define object names at runtime in C.
Wrong

#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.

void *h = LoadLibrary("variables.dll");
fn = (void (*fn)(int))GetProcAddress("GetDynamicObject");
This isn't either.
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.

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.his 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

Feb 17 '07 #23

Flash Gordon

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

santosh a écrit :

<snip>

>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?

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.
--
Flash Gordon

Feb 17 '07 #24

Flash Gordon wrote:

jacob navia wrote, On 17/02/07 19:08:
>santosh a écrit :

<snip>

>>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?

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

Feb 17 '07 #25

santosh

Yevgen Muntyan wrote:

santosh wrote:
Yevgen Muntyan wrote:
Mark McIntyre wrote:
jacob navia wrote:
Mark McIntyre wrote:

<snip>

>>#include <stdio.h>
#include <windows.h>
Beep beep. This isn't C.

<snip>

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.

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.

Feb 17 '07 #26

santosh said:

<snip>

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.

<snip>

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Feb 17 '07 #27

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!

Feb 17 '07 #28

Ian Collins

santosh wrote:

>
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.

--
Ian Collins.

Feb 17 '07 #29

santosh wrote:

Yevgen Muntyan wrote:
>santosh wrote:
>>Yevgen Muntyan wrote:
Mark McIntyre wrote:
jacob navia wrote:
>Mark McIntyre wrote:

<snip>

>>>>>#include <stdio.h>
>#include <windows.h>
Beep beep. This isn't C.

<snip>

>>>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.
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.

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

Feb 17 '07 #30

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

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]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Feb 17 '07 #31

Flash Gordon

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

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.

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.
--
Flash Gordon

Feb 18 '07 #32

CBFalconer

Yevgen Muntyan wrote:

>

.... 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

Feb 18 '07 #33

On Sat, 17 Feb 2007 20:08:57 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

(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

Feb 18 '07 #34

On Sun, 18 Feb 2007 11:15:17 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>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

Feb 18 '07 #35

Mark McIntyre said:

On Sat, 17 Feb 2007 20:08:57 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

<snip>

>>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.

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.

>>There are then NO PROGRAMS WRITTEN IN C.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Feb 19 '07 #36

Mark McIntyre wrote:

On Sun, 18 Feb 2007 11:15:17 +1300, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>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...

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.

>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.

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

Feb 19 '07 #37

CBFalconer

Yevgen Muntyan wrote:

>

.... 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

Feb 19 '07 #38

boa

CBFalconer wrote:

Yevgen Muntyan wrote:
... 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.

Chapter & Verse, please ;-)

Boa

Feb 19 '07 #39

CBFalconer wrote:

Yevgen Muntyan wrote:
... 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.

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

Feb 19 '07 #40

Yevgen Muntyan a écrit :

CBFalconer wrote:

>Yevgen Muntyan wrote:
... 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.

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

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense. Besides, windows is considered harmful
here...

It is hopeless.

Feb 19 '07 #41

jacob navia said:

<snip>

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense.

No. Whilst the criterion is indeed simple, that isn't it. The criterion
is simply that, if the code makes use of non-standard extensions, it's
off-topic here.

Besides, windows is considered harmful here...

By some, yes, but that's irrelevant. What *is* relevant is that Windows
is considered off-topic here.

It is hopeless.

It depends what you want. If you want a newsgroup where Windows
programming is topical, hope can be found at
comp.os.ms-windows.programmer.win32 - and if you want a newsgroup where
what you call "Navia C" is topical, it is likely - or at least possible
- that comp.compilers.lcc will prove hopeful for you. But if you want a
newsgroup where the C programming language, unfettered by extensions,
is discussed, then comp.lang.c is that newsgroup.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Feb 19 '07 #42

CBFalconer <cb********@yahoo.comwrites:

Yevgen Muntyan wrote:
>>
... 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.

It is a "conforming program", as defined in C99 4p7, as long as
there's some conforming C implementation that accepts it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Feb 19 '07 #43

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE
and all the other nonsense. Besides, windows is considered harmful
here...

It is hopeless.

It is hopeless as long as you have that attitude.

I've been reading your postings here for a long time. Trust me on
this: sarcasm doesn't work for you. It's not possible to have a
constructive discussion with you if you insist on parodying what you
think are other people's opinions. It simply guarantees that you will
not be taken seriously.

On the other hand, if you write what *you* believe, and perhaps even
back it up with evidence, the worst that can happen is that people
will disagree with you. It's even possible that somebody might learn
something.

I've told you this before, and I'm not optimistic that it will get
through this time.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Feb 19 '07 #44

On Mon, 19 Feb 2007 06:30:00 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>CBFalconer wrote:

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

I'm afraid I can't understand this.

What CBF was trying to say is the <and "" forms of #include
potentially search different places. By convention. the <form
searches your system header paths, while "" searches
application-specific paths. However this has nothing to do with
whether a header is ISO standard or not, so the point isn't relevant.

>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".

It is _potentially_ a C programme. However since we have no idea at
all what is in "windows.h", we can't tell what nonstandard and
nonportable atrocities might be therein. Any one of these could render
the code no longer C.

The point CBF was making here is that had the user supplied the
contents of windows.h, we oculd have been certain whether it was C or
not. As it is, it could be packed with assembler, platform-specific
memory access which violates C standards, etc etc etc.
--
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

Feb 19 '07 #45

On Mon, 19 Feb 2007 12:57:02 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Look. The criteria is simple. If I wrote it, it
it is "NOT C", "IT IS NAVIA C", IT IS WRONG, IT IS NON PORTABLE

Don't be such an idiot. The criterion is simple - if it contains
platform-specific stuff its offtopic here, irrespective of who wrote
it. If it contains nonstandard constructs, grammar etc then its not C.
Again irrespective of who wrote it.

>and all the other nonsense. Besides, windows is considered harmful
here...

Bullshit. Now you're displaying your own prejudices.

>It is hopeless.

I agree. You are determined to martyr yourself on a nonexistent altar,
no point trying to stop you I think.
--
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

Feb 19 '07 #46

CBFalconer

boa wrote:

CBFalconer wrote:
>Yevgen Muntyan wrote:
... 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.

Chapter & Verse, please ;-)

>From N869:

6.10.2 Source file inclusion

Constraints

[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.

Semantics

[#2] A preprocessing directive of the form

# include <h-char-sequencenew-line

searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.

Note that no such actual file need exist, and that the response to
the #include <filenamemay be entirely contained within the
compiler.

--
<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

Feb 20 '07 #47

Mark McIntyre wrote:

On Mon, 19 Feb 2007 06:30:00 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>CBFalconer wrote:

>>No it isn't. If it had #include "windows.h" it would be.
I'm afraid I can't understand this.

What CBF was trying to say is the <and "" forms of #include
potentially search different places. By convention. the <form
searches your system header paths, while "" searches
application-specific paths. However this has nothing to do with
whether a header is ISO standard or not, so the point isn't relevant.

Now I got it, I didn't notice <vs "". Well, that's a wrong statement.
C standard says as much about #include "windows.h" as about
#include <windows.h>. Namely, using either form makes your program
not strictly conforming. And if you talk real compilers, you can
make the compiler pick your header instead of system one
when you use #include <windows.h>, and vice versa. In any case,
it's out of standard business. So are we talking about common
sense here or about what?

>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".

It is _potentially_ a C programme. However since we have no idea at

Yes you do. That's the point. You know pretty well the program was
a C program but you wanted to tell couple nice words to Jacob Navia,
so you did "beep beep not C". Bullshit.

all what is in "windows.h", we can't tell what nonstandard and
nonportable atrocities might be therein. Any one of these could render
the code no longer C.

Yes it could, sure.

The point CBF was making here is that had the user supplied the
contents of windows.h, we oculd have been certain whether it was C or
not. As it is, it could be packed with assembler, platform-specific
memory access which violates C standards, etc etc etc.

Well, the point was hidden pretty well. This is obvious, the
non-standard header may do what it wants to. So why do you
say *not C* if you do *not* know that? I simply assume that
header is indeed the famous windows.h thing, windows C api,
for C programs. You?

Yevgen

Feb 20 '07 #48

Mark McIntyre said:

You are determined to martyr yourself on a nonexistent altar

An altar could be arranged.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Feb 20 '07 #49