Re: Automatically generate variables

Yevgen Muntyan wrote, On 24/02/07 11:21:
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.

He does tend to get a more extreme reaction that a newbie would because he knows the scope of the group but flouts it anyway.

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.

I agree that it is a valid way to do an extension, MS are actually quite good in that respect. However, it violates the syntax of C because C syntax does not allow adding anything at that point of a declaration. Just to be clear, using __whatever to add it was doing the right thing.

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

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 (the Windows API with comments showing a suggested Unix alternative) but also relied on external programs that in general are *not* installed on machine.

<anip>

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

Well, the C standard does not know about anything that is *not* C code so it does not have to make the distinction between C code and code that is not C.

How about "C program is a program consisting of C code" anyway?

A C program consists *only* of C code.

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

If I remember the post correctly it relied on there being a C compiler on the target, where generally there is not, and on the ability to dynamically load executable (which is only common on hosted systems, but probably not available on *all* hosted systems). So in this particular case the bulk of what the program was assuming was actually system specific (and available as much through any other language in the same way) rather than being C. It was probably close to "replace { with begin, } with END; and int main() with PROGRAM FRED;" and you would have a Pascal program in the same sense that you are calling it a C program. If hanging 10% changes it to another language, but getting it to run on a different system means changing 90% then is it really a C solution?

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

Topicality is enforced to keep the experts here and so keep the group valuable. Jacob gets extreme reactions because of how often he has flouted topicality pushing either Windows specific code or his own extensions to C.

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

In that extreme case, just provide the empty header as well and it can safely be called C code.

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

As far as I can see the standard only considers it to be C if it can be compiled, so if it includes a header that does not exist then it is just plain broken.

If you say "this header defines the prototypes for these non-standard functions" then we can consider everything apart from those non-standard functions as C.

I do not see a need to say that even an entire file is C or not C, this is why I emphasise that it is the code that is C or not C since then you can graduate it as finely as you need.

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

Given a reason to suppose that the C compiler will succeed (headers need not actually be files) then yes, I would consider it to be a line of C code.

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.

Yes, because then it is just a number of additional C translation units.

If you use linker, it becomes non-standard,

The linker has nothing to do with it. After all, when combining multiple translation unites (which is allowed by C) you are linking!

> i.e. just as standard-C
as embedded assembly.

<sigh> No, because everything is standard C! It matters not to me whether I have written the XML library in C or whether someone else has. If the library is in C and my code using it is in C then everything is in C. However, if the library is in assembler (or I do not know it is C) then what I have is C+XML-library rather than just C. If the XML library is written in assembler then you can call it either C+XML-library or C+assembler, your choice, if you do not know what the XML-library is written in then all you can do is call it C+XML-library.

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

No, if the libraries I am reliant on are C (i.e. part of what is defined by the standard as C or written in C, with this applied recursively) then the program as a whole is C. If somewhere along the line you reach something that is not C (i.e. not written in C or not part of the standard C library) then the program as a whole is C+whatever-is-not-C even though the headers describing the interface to the not-C may themselves be C.

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

So you call it "C+Windows API" and I call it "Windows-C" (yes, I know I've paraphrased you). That does not actually look like quite so far apart. It is more that I and some others (particularly when dealing with certain people who show repeated disregard for topicality) put more emphasis on the "+Windows API", and even more so when almost every line is either using the Windows API or setting things up to use the Windows API.
--
Flash Gordon
.

Relevant Pages

  • Re: V6 Suggestion
    ... Almost no VM is reflexive if that is what you mean, and Dolphin also has the compiler "outside" of the living smalltalk, as many low level behaviour which uses standard windows API, for performance and Windows coupling, I guess. ...
    (comp.lang.smalltalk.dolphin)
  • 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 ... if the question was "how much of the program is standard C?" ... that it's just as non-standard as my version. ...
    (comp.lang.c)
  • Re: API declarations and 64-bit C/C++ code portability
    ... I still wonder how we should write our API code ... ... but if the Windows API changes ... >big joke. ... which just aren't supported by the standard (and presumably never will ...
    (microsoft.public.win32.programmer.gdi)
  • 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)