Re: Automatically generate variables

Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 21:22:
Flash Gordon wrote:
Yevgen Muntyan wrote, On 23/02/07 13:33:
Richard Bos wrote:
Yevgen Muntyan <muntyan.removethis@xxxxxxxx> wrote:

Richard Bos wrote:
You're the one using non-Standard extensions and claiming they're
perfectly good C. I suggest that _you_ come up with your definition of
what is and is not a C program. Be careful, now: some definitions are
trickier than they first seem. For example, simply replying "any
conforming program" would have some unforeseen consequences...
Try reading the thread, you'll find some discussion of this, what
you're saying and more.

What I find is a whole lot of "yes it is", "no it isn't", "yes it is";
but nothing that makes it clear what _you_ consider to be C. Since
you're the one who is telling the rest of us that we're wrong, perhaps
you'd like to enlighten us, rather than just contradicting.

Well, since it's indeed hard to read, and much easier just to pick
some words and argue about them, I'll quote myself:

-----------------------------------------------------
... we have a choice here: call a "C program" only
strictly conforming programs or use a wider definition. The former

<snip>

I personally don't have that wider definition, and I don't think
anyone could come up with something sensible here.

In other words you think everyone who places any kind of limit on what a C program is is wrong.

#include <crapit>
BEGIN
print "This is C"
END

Must be C by your definition since crapit might possibly be a header that makes it C. Or it might be a header that makes it C++ but not C. Or maybe some other language.

Yes, it *could* be a C program, and it's indeed not hard to write that
crapit. It all depends on what in <crapit>, and whether compiler
will accept that crapit.

It was indeed carefully constructed so that given an appropriate include then you would have C code that compiles in to a C program.

> In case of original program using windows.h
you *do* know what windows.h is, and you do know that's a C program.
If you don't know what windows.h was, you can ask.

Others have pointed out that there is more than one header file called windows.h which are there for different purposes.

Yeah, "others". Of course there are many windows.h files, I can write
about zillion more using my favorite shell. But the windows.h header was
a windows C api header. If you don't know that, just ask ;)
For instance, I knew it was *the* windows windows.h header because the
code was posted by one famous portable-code-writer comp.lang.c regular.

The ones provided by MS has IIRC things which are not legal C syntax in them (the way calling conventions etc are specified).

If you mean things like __declspec, they are fine,
implementation-specific extensions. Program wasn't portable and nobody
said it was, so it's fine (and windows.h is indeed a part of
implementation). But the program itself used a nice #include
directive, which has well-defined (or rather well-understood and
well-agreed-on) semantics and the rest of code was real C code. A C
program.

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

Actually, a highly system specific program could be topical within certain limits depending on what the question being asked along with the program is. For example, if the question was "how much of the program is standard C?" then it could be considered an entirely topical post even if the only thing standard was the declaration of main. It could even lead to interesting discussions about why certain things were not covered by the standard.

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

No, it is a POSIX-C program or a Windows-C program or whatever. If well written a large percentage of the code may well be C code, but that does not make it as a hole a C program whether it uses __asm() to introduce some assembler code, or calls a function written by the author in assembler, or calls a function written by MS or the GNU team in something other than C. You could call it a "mostly C program" if you prefer.

Personally I tend to talk about C code rather than C programs. There is a lit more C code around than C programs, and it could even be that you have a 10000 line file with 5 lines of C code in it!

So you prefer to use "C code" for C code, and call only strictly
conforming programs "C programs"? Completely fine for me, but note
that it's just as non-standard as my version. And just as vague.
It's as vague because for instance your above example with crapit
again could be C code, if you insert appropriate defines. From the
other hand, any C code may be screwed up using macro definitions.

The code as presented was not C code. If it was presented with appropriate headers then the complete set could be C code.

And we get back to the fact that it's possible to say for sure
if something is standard C or not only for complete program.

No, not a complete program, just enough if it to not rely on things which are not C.

Once you start saying

int a = 2;

or

int func (void)
{
return 0;
}

is C code, you get away from the safe route (standardise) and get to
area of "it looks and breathes like C", the stuff I am talking about.

In other words, you are saying my "definition" (which I don't really
have) is no good, and you just use another one, which is just as
non-strict as mine. Then you can ignore the question about what
"C programs" are since you can think about "C code" instead :)

I made some attempt to provide some kind of scope to what is and is not C, although it is not perfect. You, on the other hand, just said that it might be C even if it goes beyond what the standard defined and gave no outer limit on what could be considered C.

Well, the standard does *not* define what is "C code". I understand
what you mean, you understand what you mean, but it's not what
standard says. Standard doesn't know what it means "N% of C code"
or "two lines of C code".
How about "C program is a program consisting of C code" anyway?

With no such limits then this entire post is C because for all you know it could be an extract from a file that has /* before what is shown here and closes the comment after. So you have to put some limit on what you consider to be C code, you don't have to make an attempt to tell us what it is, but if you don't then don't complain when others express there opinion that something is not C code.

Yeah yeah, "opinion". Now do go back and read that very post, where
"others" "expressed their opinion". It wasn't "given that I have no
clue what windows.h I can't make a conclusion if it's C or not". No, it
was "fsking no, it's non-standard therefore not C", an emotional
response caused by feelings of one person to another one.
*If* someone was interested in that program he could ask what windows.h
was. If someone wasn't interested in it, he could ignore it. But "not
C because I pretend I have no clue what it is" is nonsense.
Oh well.

-----------------------------------------------------

A long quote, but it was hard enough to write that, and I didn't
try to edit/compress it.

It does not address what you think is and is not C, it only says you don't agree with C code being only code which is specified (possibly as being implementation defined) by the C standard.

I didn't discuss "C code" term at all. I can tell that it seems
we have same ideas about what is C code and what isn't though.

I introduced it because in my opinion "is it C code?" is a far more useful question than "is it a C program?"

<snip>

How do you distinguish "C code" from "pseudo-C crap". As far as the
standard is concerned, once you have any non-standard #include
in your file, you get "pseudo-C crap".

Only if the non-standard header is not provided or is not itself C code. If the non-standard header has no impact on the rest of the file then only that one line is "pseudo-C crap", if you don't know the contents of the header then the entire presented code can validly be considered as "pseudo-C crap".

You see, here I tightened up the definition up so that my earlier example given on its own because "not C code".

You miss the important fact here. If you have a non-standard #include
in your C code, it may fail to be processed by a conforming C compiler.
Even if that header is empty, for instance. You are saying that it's
C code because reasonable compiler will indeed process it; or because
you can expand #include manually; or for whatever else reason. But the
standard doesn't agree. I, from the other hand, claim that it's totally
fine to say it's a C program (or C code if you prefer), even though
it's not standard.


> Once you have one file in
your program which uses a non-standard feature (even if the other
thousand files are perfect standard C), then the program is "pseudo-C
crap". So the question stands. You like to write pseudo-C crap,
it's fine; I still believe there are lot of C programmers writing
C programs, which are C programs even if they use POSIX api, windows
api, foobar api, etc.

Personally since I started writing C hardly any programs I have written have been C programs (or do yo consider " LAC *+,AR0" to be C?)

It can't be made C even using preprocessor tricks, so it's not C at all.
I guess.

The point was there is a program where 90% or more is completely standard C. Then there are a few linker tricks to get some variables which are only ever declared as "extern" in the C mapped on to some hardware (so the C code is not having to do tricks like converting integers to pointers to access memory mapped devices). Then there are one or two assembler files making up under 10% of the code. So 90% is C but a small fraction is not, and the status of the 90% as being C code is far more important than the status of the program as a whole.

I can't disagree here. Anyway, do you count #include <cheader.h> as
C code? As well as #include "cheader.h" (sure, provided the complete
listing of cheader.h is available, the standard doesn't say it will
help).

but I have written a lot of C code that has been incorporated with other stuff to produce programs.

Somehow almost all programs on my computer are written in C. You
may say they are written in "Pseudo-Unix pseudo-C crap", it's your
choice. But it's not a sensible choice.

A lot of programs are written mostly in C, but if the program as a whole is not written in C then calling it a C program is misleading, although saying it is mostly written in C is not.

If I write a program with 25% assembler, 25% C, 25% Java and 25% Fortran, what language is the program written in? My answer is "a mixture".

Yes, it's a mixture. But I wasn't talking about such cases. I was
talking about programs which have 100% C code. Using non-standard
features like "libraries" though.

Those libraries are written in something. If they are written in C then expand your scope to include them and you have a C program (I use XML libraries which are at least mostly written in C for example).

"Expand scope", huh? If you include their source files, it's standard.
If you use linker, it becomes non-standard, i.e. just as standard-C
as embedded assembly. But the result is the same, the point is the same:
you have a C program (program consisting of C code if you prefer), you
use C headers.

However, if either those extras are not C *or* you are not including them in what you are presenting, then what you are presenting is no longer C but C+whatever or Windows-C or POSIX-C.

Note that a header that is not part of standard C and is not provided as part of what is presented could easily contain things which convert your program from being valid C to being valid some-other-language. C is not the only language to use #include! I would assume it was C+something but I could not be completely convinced, because I do know that there are files called windows.h which are nothing to do with MS Windows.

Well, I just made an (completely reasonable) assumption that the
windows.h thing was indeed *that* windows.h thing. You can have
reasonable doubt in it, since it may or may not have been that
windows.h. But can you just claim "not C" because I/he didn't tell
what windows.h was? Can you tell that "beep beep not C" is just
as reasonable as my "I believe it's C program which uses windows
api"?

Yevgen
.

Relevant Pages

  • Re: Automatically generate variables
    ... Must be C by your definition since crapit might possibly be a header that makes it C. ... I knew it was *the* windows windows.h header because the ... Given certain assumptions the C code was valid C code, however from what I remember it certainly was not a C program solving the problem since it not only relied on non-C APIs but also relied on external programs that in general are *not* installed on machine. ... You, on the other hand, just said that it might be C even if it goes beyond what the standard defined and gave no outer limit on what could be considered C. ...
    (comp.lang.c)
  • Re: Automatically generate variables
    ... Must be C by your definition since crapit might possibly be a header that makes it C. ... if the question was "how much of the program is standard C?" ... that it's just as non-standard as my version. ... If the non-standard header has no impact on the rest of the file then only that one line is "pseudo-C crap", if you don't know the contents of the header then the entire presented code can validly be considered as "pseudo-C crap". ...
    (comp.lang.c)
  • Re: error C2061
    ... That looks suspiciously like a windows header. ... Try a group that deals with Microsoft or Windows. ... He might have reported similar behavior when including a standard ... been examined and criticized by multiple experts on the subject. ...
    (comp.lang.c)
  • Re: Dialog: colorizing header list
    ... Yes, but if I set that to i.e. half-grey, then, when using standard ... Windows' colors in the system, I can't see the "From, Subject, Date" ... etc. header, because the bg and text ...
    (news.software.readers)
  • Re: Non-English Validation Expression for email address?
    ... The Internet Engineering Task Force has published three crucial documents for the standardisation of email address headers that include symbols outside the ASCII character set. ... This means that soon you'll be able to use Chinese characters, French accents, and German umlauts in email addresses as well as just in the body of the message. ... They say there would need to be an "upgrade mania" if the Unicode standard UTF-8 is to replace the American Standard Code for Information Interchange currently used as the general email language. ... A new header field will be added as a sort of "emergency parachute" to ensure that UTF-8 emails have a soft landing if they are thrown out before reaching the recipient by systems that have not been upgraded. ...
    (microsoft.public.dotnet.framework.aspnet)
Loading