Related
I've started working with Turbo C 2.01 as a hobby project. Yes, the DOS version. Since it came out in 1987, I assume it doesn't support C90... except it does. Well, pieces of it. The volatile keyword works. And straight K&R isn't supported; I tried K&R style declarations, to an error.
So, I was wondering what form of C Turbo C uses. I'm sure it's nonstandard, but it seems somewhat consistent, and since this was a very popular compiler back in the day, I'm sure there's some collection of information... right?
There was no real standard back then, and additionally MS-DOS had its own quirks (namely the segmented memory model, and different application memory models using them differently...).
So I think it's safe to say, Turbo C 2.01 uses Turbo C 2.01 dialect of C.
About supporting C90, note that the standard obviously did its best to have existing C code be compatible with it. So it's not surprising Turbo C from 87 can build most C90 programs with minimal changes.
According to wikipedia, original K&R non standard spec came out in 78. The starting point of the ANSI X3J11 committee that produced the ANSI C89 standard is 1983, and the goal was
to establish a standard specification of C. X3J11 based the C standard on the Unix implementation.
That standard was then adopted by ISO as C90. But as it was extensively based on an existing implementation, the extensions from this implementation were already ported in other implementations like Borland's one.
So there is no real suprise that Borland C2.01 from 87 already includes most of the extensions to K&R C that has been adopted in standard only 2 years later.
I have started programming practice on codechef and have been confused by the difference between C and C99. What does C mean here? Is it C89? Check the languages at the bottom of this submit. It contains both C and C99.
I found on the internet something called GNU C. Is there a different C for linux/unix systems? Are these compliant to the C standards by ANSI? I have also read in some places "C99 strict". What is this?
Are there any other different standards of C in use? Is there something called C 4.3.2 or is it the gcc version in current use?
EDIT:
This, This, This helped. I'll search more and edit the things that are left unanswered.
I am not a programming newbie. I know what C language is. I know that there are the different C standards by ANSI like C89, C99 and C11.
Everything before standardization is generally called "K&R C", after the famous book (1st edition and 2nd edition), with Dennis Ritchie, the inventor of the C language, as one of the authors. This was "the C language" from 1972-1989.
The first C standard was released 1989 nationally in USA, by their national standard institute ANSI. This release is called C89 or ANSI-C. From 1989-1990 this was "the C language".
The year after, the American standard was accepted internationally and published by ISO (ISO 9899:1990). This release is called C90. Technically, it is the same standard as C89/ANSI-C. Formally, it replaced C89/ANSI-C, making them obsolete. From 1990-1999, C90 was "the C language".
Please note that since 1989, ANSI haven't had anything to do with the C language, other than as one of many instances working on the ISO standard. It is nowadays done in USA through INCITS and the C standard is formally called INCITS/ISO/IEC 9899 in USA. Just as it is for example called EN/ISO/IEC in Europe.
Programmers still speaking about "ANSI C" generally haven't got a clue about what it means. ISO "owns" the C language, through the standard ISO 9899.
A minor update was released in 1995, sometimes referred to as "C95". This was not a major revision, but rather a technical amendment formally named ISO/IEC 9899:1990/Amd.1:1995. The main change was introduction of wide character support.
In 1999, the C standard went through a major revision (ISO 9899:1999). This version of the standard is called C99. From 1999-2011, this was "the C language".
In 2011, the C standard was changed again (ISO 9899:2011). This version is called C11. Various new features like _Generic, _Static_assert and thread support were added to the language. The update had a lot of focus on multi-core, multi-processing and expression sequencing. From 2011-2017, this was "the C language".
In 2017, C11 was revised and various defect reports were solved. This standard is informally called C17 or C18. It was finished in 2017 (and uses __STDC_VERSION__ = 201710L) but was released by ISO as 9899:2018, hence the ambiguity between C17/C18. It contains no new features, just corrections. It is the current version of the C language.
A draft called "C23"/"C2X" is work in progress by the committee, planned to be released in 2023. The current working draft can be found here, at this point called N2731, last changed 2021-10-18.
This contains a lot of minor defect report fixes like C17/C18 but also some major changes, most notable (so far):
the removal of exotic signedness representations in favour of mandatory 2's complement
final removal of "K&R-style" function definitions (flagged obsolescent since C99)
some new functions added including memccpy and strdup
some new function attributes from C++ deprecated, fallthrough, maybe_unused, and nodiscard
binary 0b notation for integer constants (currently not listed as one of the changes to N2731 but present on p.51 of the draft).
"C99 strict" likely refers to a compiler setting forcing a compiler to follow the standard by the letter. There is a term conforming implementation in the C standard. Essentially it means: "this compiler actually implements the C language correctly". Programs that implement the C language correctly are formally called strictly conforming programs. Such programs may also not contain any form of poorly-defined behavior.
"GNU C" can mean two things. Either the C compiler itself that comes as part of the GNU Compiler Collection (GCC). Or it can mean the non-standard default setup that the GCC C compiler uses. If you compile with gcc program.c then you don't compile according to the C standard, but rather a non-standard GNU setup, which may be referred to as "GNU C". For example, the whole Linux kernel is made in non-standard GNU C, and not in standard C.
If you want to compile your programs according to the C standard, you should type gcc -std=c99 -pedantic-errors. Replace c99 with c17 if your GCC version supports it.
I MUST respond regarding ANSI C. Although ANSI has not done anything with it, compilers are still built to it. PIC XC16 compiler for example:
"The compiler is a fully validated compiler that conforms to the ANSI C
standard as defined by the ANSI specification (ANSI x3.159-1989) and
described in Kernighan and Ritchie’s The C Programming Language (second
edition). ..."
Not all programming is for "big" computers like PCs. Writing a compiler for your device costs, and validating costs time & $. ANSI C is alive & well &
living in your embedded / real-time devices.
ANSI C :
The first C language was standardized by the body called ANSI in 1989 that's why it is called c89.
C99 :
with the demand from the developers requirements, in 1999-2000 further or additional keywords and features have been included in C99 (ex: inline, boolean.. Added floating point arthematic library functions)
GNU C: GNU is a unix like operating system (www.gnu.org) & somewhere GNU's project needs C programming language based on ANSI C standard. GNU use GCC (GNU Compiler Collection) compiler to compile the code. It has C library function which defines system calls such as malloc, calloc, exit...etc
ANSI C is a standard which is being used by or refereed the other standards.
In Addition To Lundin Answer
Here is What Dennis Richie Has To Say When Asked
"Why didn't K&R wait for the final, approved ANSI standard before writing K&R 2nd edition?"
Why didn't K&R wait for the final, approved ANSI standard before writing
K&R 2nd edition? It seems like this book will only be the correct standard for
a few months before it will be supesceded by the final ANSI standard. I know
that there are likely to be few major changes at this late stage, but why not
wait a few months and make sure you get it 100% right, rather than needing to
almost immediately write a 3rd edition or be obsolete?
We thought it would be nice to mark the 10th anniversary
of the first edition.
More seriously, we started work last summer because we had the
time and inclination then, and it appeared that X3J11 was approaching
an end. In December and January, as we were finishing, we considered
whether the possibility of important changes warranted putting off
delivery, and (after discussing the matter with the publisher)
decided that it was not worth waiting. P-H wanted it, and both
Brian and I wanted it off our agendas.
Even if there are changes in the standard, it's hard to imagine
that they would be extensive enough to warrant a new edition.
(We were even prepared to cope somehow with noalias, if it had lasted.)
We're ready to make necessary changes in a future printing,
but there's reason to hope that they should be minor. X3J11's
members are very anxious to finish without surprising people, too;
many of them work for companies that are preparing ANSI compilers,
after all.
Dennis Ritchie
This question was not thoroughly searched on net for answer ,anyway you may look at this :
C is a general-purpose programming language initially developed by
Dennis Ritchie between 1969 and 1973 at AT&T Bell Labs.
C99 is a standard of the C language published by ISO and adopted by ANSI in around 1999.
GNU C is just an extension of c89,while some features of c99 are also added,but in entirety it is different from c99 standard so when compiling in gcc we have to enter -std=c99 which is already mentioned in the other answers.
ANSI C is a successive series of standards released by ANSI.
Overview:
I'm working with a hobby app. I want my program to be able to stick to "plain C".
For several reasons, I have to use a C++ compiler, and the related programming enviroment program, that supports "Plain C". And, for the same reasons, I cannot change to antoher compiler.
And, there are some C++ features that I have been coded, unintentionally.
For example, I'm not using namespaces or classes. My current programming job, is not "plain c" or "c++", and I haven't used them for some time, so, I may have forgotten which stuff is "plain c" only.
I have browsed in the internet, for "Plain C" examples. I have found that many other developers, have also post mixed "plain c" & "c++" examples, (some of them unintentionally).
I'm using some dynamically allocated structures. I have been using "malloc", but I rather use "new" instead. I thought that some new standard & compiler versions of "plain c" allowed "new", but, seems I'm wrong.
Seems that "new" is a "C++" feature, & if I really want to make a only "plain c", I should use "malloc".
The reason I want to stick to "plain C", it's because I'm working in a cross platform non-gui library / tool.
My current platform is "Windowze", my Development Enviroments, are:
(1) CodeBlocks (MinGW)
(2) Bloodshed DevCPP
(3) Borland CBuilder 6
Although, my goal is to migrate it to Linux, too , and maybe other platforms, and other (command-line) compilers.
Quick not Tested Example:
#include <stdio.h>
#include <stdlib.h>
#include <strings.h>
struct MyData_T
{
int MyInt;
char MyName[512];
char *MyCharPtr;
};
typedef
struct MyData_T *MyData_P;
MyData_P newData(char* AName)
{
MyData_P Result = null;
Result = malloc(sizeof(MyData_T));
strcpy(Result->MyName, AName, strlen(AName));
// do other stuff with fields
return Result;
} // MyData_P newData(...)
int main(...)
{
int ErrorCode = 0;
MyData_P MyDataVar = newData("John Doe");
// do more stuff with "MyDataVar";
free(MyDataVar);
return ErrorCode;
} // int main(...)
Questions
Where I can get a working "plain c only" compiler for x86 (windowze, linux) ?
Should I stick to use "malloc", "calloc", and similar ?
Should I consider to change to "C++" & "new", instead ?
Is it valid to use "new" & "delete" in a "plain c" application ?
Any other suggestion ?
Thanks.
Disclaimer
Note: I already spent several hours trying not to post the same question, in Stackoverflow, but, none of the previous answers seem clear to me.
Remember that C and C++ are actually completely different languages. They share some common syntax, but C is a procedural language and C++ is object oriented, so they are different programming paradigms.
gcc should work just fine as a C compiler. I believe MinGW uses it. It also has flags you can specify to make sure it's using the right version of C (e.g. C99).
If you want to stick with C then you simply won't be able to use new (it's not part of the C language) but there shouldn't be any problems with moving to C++ for a shared library, just so long as you put your Object Oriented hat on when you do.
I'd suggest you just stick with the language you are more comfortable with. The fact that you're using new suggests that will be C++, but it's up to you.
You can use e.g. GCC as a C compiler. To ensure it's compiling as C, use the -x c option. You can also specify a particular version of the C standard, e.g. -std=c99. To ensure you're not using any GCC-specific extensions, you can use the -pedantic flag. I'm sure other compilers have similar options.
malloc and calloc are indeed how you allocate memory in C.
That's up to you.* You say that you want to be cross-platform, but C++ is essentially just as "cross-platform" as C. However, if you're working on embedded platforms (e.g. microcontrollers or DSPs), you may not find C++ compilers for them.
No, new and delete are not supported in C.
* In my opinion, though, you should strongly consider switching to C++ for any application of non-trivial complexity. C++ has far more powerful high-level constructs than C (e.g. smart pointers, containers, templates) that simplify a lot of the tedious work in C. It takes a while to learn how to use them effectively, but in the long run, they will be worth it.
GCC has a C compiler. It's the basic one. You can call it with gcc -std=c90 to make sure it doesn't slip in any Gnu or C++ extensions.
Yes, malloc/calloc are portable and safe for use in C
Only if you have some reason to switch to C++… C is a bit more portable, but not by much, these days.
The most important tip is to save your file with a .c extension and disable compiler extensions. On both Visual C++ and gcc (and thus MinGW) this makes them go into C mode, where C++ additions will be disabled.
You can also force C mode using -std=c90 (or c99, depending on the C standard you want to use; these also disable GNU extensions) in gcc, /Tc in VC++ (and here to disable MS extensions you have to use /Za).
If using visual studio, just make the file .c (though its not strictly a C compiler, it pretends to be, and for the most, is good enough)
*nix world you can use gcc, as its pretty much the standard.
If you want to do C stick to C, if you want to do C++, use C++
so stick with malloc etc.... in C++ you'd use smart pointers.
You don't have to stick with C to create cross platform non-GUI library. You can as well develop that in C++. Since it is hobby, it is OK, but there are such libraries already available.
It seems that starting with C17 (or the technical name ISO/IEC 9899:2018) the new keyword is being supported. To make this work, if you're using Visual Studio Code, in the c_cpp_properties.json file update:
"cStandard": "c17", and
"cppStandard": "c++17"
I'm looking into learning C basics and syntax before beginning Systems Programming next month. When doing some reading, I came across the C89/99 standards. According to Wikipedia,
C99 introduced several new features,
including inline functions, several
new data types (including long long
int and a complex type to represent
complex numbers), variable-length
arrays, support for variadic macros
(macros of variable arity) and support
for one-line comments beginning with
//, as in BCPL or C++. Many of these
had already been implemented as
extensions in several C compilers.
C99 is for the most part backward
compatible with C90, but is stricter
in some ways; in particular, a
declaration that lacks a type
specifier no longer has int
implicitly assumed. A standard macro
STDC_VERSION is defined with value 199901L to indicate that C99 support
is available. GCC, Sun Studio and
other compilers now support many or
all of the new features of C99.
I borrowed a copy of K&R, 2nd Edition, and it uses the C89 standard. For a student, does the use of C89 invalidate some subjects covered in K&R, and if so, what should I look out for?
There is no reason to learn C89 or C90 over C99- it's been very literally superseded. It's easy to find C99 compilers and there's no reason whatsoever to learn an earlier standard.
This doesn't mean that your professor won't force C89 upon you. From the various questions posted here marked homework, I get the feeling that many, many C (and, unfortunately, C++) courses haven't moved on since C89.
From the perspective of a starting student, the chances are that you won't really notice the difference- there's plenty of C that's both C99 and C89/90 to be covered.
Use the C99 standard, it's newer and has more features. Particularly useful may be the bool type in <stdbool.h> and the int32_t etc. family of types; the latter prevents a lot of unportable code that relies on ints having a certain size. AFAIK, it doesn't invalidate K&R, though some example programs may be written in a slightly different style now.
Note that some compilers still don't support C99 properly. I believe that GCC still requires the use of a -std=c99 flag to enable it; many Unix/Linux systems have a c99 command that wraps GCC and enables C99.
The same goes for many university professors. I surprised mine by handing in a program that used bool in my freshman year. He'd never heard of that type in C :)
While I generally agree with the others, it is worth noting that K&R is such a good book that it might be worth learning C from it and then updating your knowledge as you read about the C99 standard.
If you are at student level you probably won't even notice the differences.
Yes, it's a bit odd that you can get a loud consensus that K&R is a great C book, and also a loud consensus that C99 is the correct/current/best version of C. The two positions are incompatible - even if K&R is the best book available to learn "C meaning C99", that just implies the rest are rubbish, or are also hopelessly outdated.
I would advise learning and using C99, but keeping an eye to C89 as you do so. If you use a compiler that has both C89 and C99 compliant modes, then you can write a few bits of C89 just to get an idea of the differences. Then if you ever need to write some code intended to be portable to places that C99 doesn't go, you'll know what to do. If you never have to write any such code, then you've wasted perhaps a day.
Writing C89 properly is actually surprisingly difficult, because getting hold of a copy of the C89 standard is difficult. So, C99 if you can, C89 if for some odd reason you have to, and have some awareness what the difference is. Maybe use K&R to cover the very basics, but get a look at some idiomatic C99 as soon as possible.
As for specific issues to be aware of when reading K&R: there's a list of major changes in the foreword of the standard (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf), although the details aren't laid out there. A lot of them are new features added to C99, so it's not that K&R is wrong, it just may not always use the best tools for a given job. Some of them are quite fiddly things where you should probably consult the standard if you need the details anyway. The rest are things removed from C89, that usually a C99 compiler will tell you about as and when you try to use them.
As a student, that doesn't influence you so much. But if possible, you should find a new C book which covers C99
The term "C89" describes two very different languages:
The language that programmers in 1989 thought the Committee was describing in places where the Standard was ambiguous, and which supported features that were common in pre-existing implementations.
The language that the Committee has since decided that it wanted to have described, which threw compatibility with existing functionality out the
window.
C99 "clarifies" ambiguous parts of the standard by saying that they meant
to have the Standard interpreted in a way that would have broken a substantial
fraction of existing code and made it impossible to perform many tasks as
efficiently as they had been performed in C before 1989.
The right language to program in, for many applications, would be the superset of pre-Standard C, C89, C99, and C11. It's important, however, that anyone programming in that language be clear that they're using that language rather than a shrinking subset which favors speed over reliability.
While I think it's beneficial to know which features are more recent and less likely to be supported by obscure (or intentionally-broken, like MSVC) compilers, there are a few C99 features that you should absolutely use:
snprintf: This is the definitive function for safe and clean string assembly in C. If your compiler is missing it, you can either replace the whole printf subsystem (probably a good idea since most implementations with missing snprintf are also full of (often intentional) bugs in printf behavior), or wrap tmpfile/fprintf/fread/fclose.
stdint.h: If you need fixed-size types (16/32/64-bit), use the standard names int16_t, uint16_t, int32_t, etc. Do not invent your own, and absolutely don't use system-specific ones like INT64 or u32. It just makes your code ugly and hard to integrate and reuse. If your compiler is missing stdint.h, just drop in your own to define the types in terms of the correct-for-your-platform types.
Specifically uint64_t, in place of int foo[2]; or struct { int lo, int hi; } foo; or other hideous legacy hacks to work with 64-bit numbers. Any sane compiler even without C99 support has its own 64-bit types you can use to define int64_t and uint64_t.
Nearly every (relatively) new book about c programming I've seen doesn't seem to adhere to the C99 standard, or they cover it in an extra chapter. Comming from a Java background, the C99 standard made the migration (well, still migrating ^^) much easier for me, and this probably applies to other languages, too.
It seems like C99 hasn't reached most of the C developers yet. But why?
Short answer: compiler support is slow to get installed and c programmers are a conservative lot who change their behavior slowly.
I strongly suspect it's mainly because MSVC does not attempt to support C99, and quite likely never will. There are a few embedded compilers in the same boat, but they're hardly common enough to matter much individually. AFAIK everyone else is at least trying to implement C99 as much as possible.
There isn't much reason in practice not to use selected features of C99, but if you're going to learn and write to one C standard, and only one, then it must be C89.
Furthermore, it's probably quite difficult and confusing to write an introductory C text which starts out by saying "OK, there are two different standards, and I'm going to use three different colours of text: one for C89, one for C99, and one for both". It's also probably harder to write about C99 for a whole book, and then "take back" a lot of what you've said in an appendix about C89, than it is to write about C89 and then add to it in an appendix about C99.
All speculation, though. Really you'd have to ask the authors of the books you're reading (or perhaps in some cases go against all your programming instincts, and read the foreword ;-))
The risk of switching to a new compiler on an existing code base is generally unknown, but it can be quite painful, its wisest to only switch when you have months of time to shake out any bugs/changes. And for really old code bases, sometimes It's wisest to just never switch at all.
I'd be willing to bet that the majority of projects that use C aren't willing to switch to C99 at all since there's hardly any upside for a large existing code base and quite a bit of potential downside. I worked at one large software house that checked the compilers into th source tree right along side the code and would never switch compilers for a product.