ANSI C & MICROSOFT.
Henry Williams
Compatibility
The Microsoft run-time library supports American National Standards
Institute (ANSI) C and UNIX® C. In this book, references to UNIX include
XENIX®, other UNIX-like systems, and the POSIX subsystem in Windows NT and
Windows 95. The description of each run-time library routine in this book
includes a compatibility section for these targets: ANSI, Windows 95 (listed
as Win 95), and Windows NT (Win NT). All run-time library routines included
with this product are compatible with the Win32 API.
Doesn't this promise cross platform compatibility when compiling in win32
console mode?
I.E.; using the console mode as a development environment for pure ANSI c
code?
I'm learning c and it is a comforting prospect to know that your compiler is
ANSI C compliant.
Any comments appreciated.
hwil...@gower.net
Michael Rubenstein
If you stick to standard C, your programs will be very portable.
Microsoft has a few bugs, but is one of the better compilers at
complying with the standard, particularly if you compile with the -Za
option.
For Unix compatibility, its a bit chancier. Windows NT has POSIX
subsystem, but it's too brain damaged for serious use; it appears to
be there only to satisfy the letter of some requirement for bidding.
If you're careful, it's usually not too difficult to make programs
compatible between Unix and Win32 using Visual C+++ without using the
POSIX subsystem (as a C compiler -- its much more difficult if you
write in C++ because of widely varying conformance of existing
compilers).
The main exception is process creation. Visual C++ doesn't support
fork() which is pretty fundamental in Unix. There are also numerous
differences in handling interprocess communications, but they are
easier to code for, though you'll need to use conditional compilation.
If you need Unix compatibility, consider GNU C. You can get a Win32
port at http://www.cygnus.com/.
--
Michael M Rubenstein
Jack Klein
> In article <6uc5fn$jp8$1...@supernews.com>,
> Henry Williams <hwil...@gower.net> wrote:
> >An excerpt form MS Visual c 5.0 help files.
> >
> >Compatibility
> >The Microsoft run-time library supports American National Standards
> >Institute (ANSI) C and UNIX® C. In this book, references to UNIX include
>
> The second part of this is a lie. To say that you support UNIX, you
> have to comply with all of the requirements of The Single UNIX Specification.
> (Known this year as Unix98).
<Jack>
It's even worse than that, it's vaporware. Even though that statement exists
in the portability statement for MSVC 5.0, they actually removed Unix from all
of the individual help pages between 4.0 and 5.0.
We should feel blessed that they decided to leave "ANSI" in.
</Jack>
Stephan Wilms
[on the subject of Visual-C console app mode]
>
> Doesn't this promise cross platform compatibility when compiling in win32
> console mode?
"Console Applications" in Visual-C are indeed a good way to write
ANSI-C code. But you must be careful in some cases, because even
the strict ANSI-C mode does not catch a number of ANSI-C violations,
for instance:
- "void main" is accepted without warning
- "//" comments are accepted without warning
- you must be a bit careful with header and functions usage: if
you include some of the more Windows or DOS specific headers and
call the functions you do at at the cost of portability
> I.E.; using the console mode as a development environment for pure ANSI c
> code?
Yes, you can do this. I often do so myself. AFAIK Visual-C is not
100% perfect ANSI compliant, but pretty good nevertheless.
Stephan
(initiator of the campaign against grumpiness in c.l.c)
tst...@my-dejanews.com
"Henry Williams" <hwil...@gower.net> wrote:
> An excerpt form MS Visual c 5.0 help files.
>
> Compatibility
> The Microsoft run-time library supports American National Standards
> Institute (ANSI) C and UNIX® C. In this book, references to UNIX include
> Windows 95. The description of each run-time library routine in this book
> includes a compatibility section for these targets: ANSI, Windows 95 (listed
> as Win 95), and Windows NT (Win NT). All run-time library routines included
> with this product are compatible with the Win32 API.
>
> console mode?
Providing the platform you are compiling for supports the win32 api.
> I.E.; using the console mode as a development environment for pure ANSI c
> code?
> I'm learning c and it is a comforting prospect to know that your compiler is
> ANSI C compliant.
From the above, M$ supports ANSI/ISO C, it *also* supports POSIX, it
*also* supports the Win32 API. These are *separate* standards. The fact that
one (eg ANSI/ISO C) is supported does not mean that all (eg Win32) are
supported.
As it was staeted above, you have to read the compatability section of each
function description to see which is supported and where. You'll have the
greatest portability if you stick to those listed as ANSI compatible, less
portability with those listed as POSIX, and even less with those listed as
Win32.
> Any comments appreciated.
> hwil...@gower.net
>
>
--
Tristan Styles
Failure is not an option
It is Standard Operating Procedure
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
au...@cam.org
> An excerpt form MS Visual c 5.0 help files.
> Compatibility
> The Microsoft run-time library supports American National Standards
> Institute (ANSI) C and UNIX® C. In this book, references to UNIX include
> XENIX®, other UNIX-like systems, and the POSIX subsystem in Windows NT and
> Windows 95. The description of each run-time library routine in this book
> includes a compatibility section for these targets: ANSI, Windows 95 (listed
> as Win 95), and Windows NT (Win NT). All run-time library routines included
> with this product are compatible with the Win32 API.
> Doesn't this promise cross platform compatibility when compiling in win32
> console mode?
I don't think so unless your program indeed only uses ANSI C functions and
definitions. As soon as you use a specific Win32 call then forget it. Same
with DOS after all or any other system. No magic in there I think. Your DOS
C code will compile fine on a Unix system if you don't make use of any INT
calls, if all your video output is done through printf() so to speak.
Now, run-time libraries that are multi-platform compatible is another,
different thing. The text above says that the libraries provided are only
compatible with the Win32 API. So this mean your code won't run under OS/2
for instance.
On the other hand, if you use OS/2 and compile your C code using Open32 calls
that are supported in Win32, then your code can be compatible from one
platform to the other.
ANSI C and platform-specific run-time libraries are two very different
topics. I don't know of a C compiler that does not provide ANSI C support.
On the other hand, I don't know of a programmer who only uses ANSI C for
serious product development.
My two cents (Canadian of course, so that makes 1.2 cents)
Alain
> I.E.; using the console mode as a development environment for pure ANSI c
> code?
> I'm learning c and it is a comforting prospect to know that your compiler is
> ANSI C compliant.
> Any comments appreciated.
> hwil...@gower.net
Dan Pop
>"Console Applications" in Visual-C are indeed a good way to write
>ANSI-C code. But you must be careful in some cases, because even
>the strict ANSI-C mode does not catch a number of ANSI-C violations,
>for instance:
> - "void main" is accepted without warning
No warning is required by ANSI C when invoking undefined behaviour.
The compilers which actually complain about "void main" are few and far
between.
> - "//" comments are accepted without warning
This is a genuine problem, until C9X becomes the C standard.
> - you must be a bit careful with header and functions usage: if
> you include some of the more Windows or DOS specific headers and
> call the functions you do at at the cost of portability
Again, no ANSI C violation. If you include a nonstandard header, you're
invoking undefined behaviour. This "problem" is common to all C
implementations I've ever heard of, because all of them provide
nonstandard headers, besides the standard ones.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Ken Nicolson
Rubenstein) wrote:
>If you stick to standard C, your programs will be very portable.
>Microsoft has a few bugs, but is one of the better compilers at
>complying with the standard, particularly if you compile with the -Za
>option.
I found a "feature" in its -Za mode (in v5) today, as I was trying to
make a point about // not being standard C in a mailing list. Turn on
-Za and try to compile this:
#include <stdio.h>
// The example:
int main( void )
{
return printf( "%d\n", 20//*4*/5
+3 );
}
A year's supply of Herb Schlidt books if you can guess the outcome of
running this through the compiler, two years' supply if you get it
wrong...
It's 7, and turning on warning level four lets you see how MS comes to
this conclusion:
Text2.c(3) : warning C4001: nonstandard extension 'single line
comment' was used
Text2.c(6) : warning C4179: '//*' : parsed as '/' and '/*': confusion
with standard '//' comments
A smart compiler, or too smart for its own good?
Ken
Michael Rubenstein
wrote:
I don't see your point. 7 is what it should print. the expression
being printed is 20/5 + 3 which evaluates to 7.
Of course it only gives the required diagnostic (because of // The
example) at warning level 4. I'd call that a deficiency since level 4
puts out too many diagnostics to be useful, but it complies with the
letter of the standard here when level 4 is specified.
I'd like to see both warnings at a lower level and C4179 with or
without extensions enabled, but that's not a conformance issue.
Without Microsoft extensions disabled, it prints 23, which is what
will be required by C9x.
--
Michael M Rubenstein
Michael Rubenstein
>In <3609EB...@CWA.de> Stephan Wilms <Stepha...@CWA.de> writes:
>
>>"Console Applications" in Visual-C are indeed a good way to write
>>ANSI-C code. But you must be careful in some cases, because even
>>the strict ANSI-C mode does not catch a number of ANSI-C violations,
>>for instance:
....
>> - "//" comments are accepted without warning
>
>This is a genuine problem, until C9X becomes the C standard.
At warning level 4, Visual C does issue a warning about // comments.
Unfortunately, it also issues a lot of warnings about harmless
constructs which make this a problem for the user, but as far as the
standard goes one can simply say that warning level 4 is required to
make the compiler conforming.
As with every compiler, there are some bugs, but the conformance
problems I know of are not likely to be much of an issue.
--
Michael M Rubenstein
Stephan Wilms
>
> In <3609EB...@CWA.de> Stephan Wilms <Stepha...@CWA.de> writes:
>
> >"Console Applications" in Visual-C are indeed a good way to write
> >ANSI-C code. But you must be careful in some cases, because even
> >the strict ANSI-C mode does not catch a number of ANSI-C violations,
> >for instance:
>
> No warning is required by ANSI C when invoking undefined behaviour.
Especially since this is often hard or impossible for the compiler
to detect. I just troed to list a few things from the top of my head.
> The compilers which actually complain about "void main" are few and far
> between.
Yes, I guess so. I am probably a bit spoiled since my other compiler
that I frequently use does complain about it.
> > - you must be a bit careful with header and functions usage: if
> > you include some of the more Windows or DOS specific headers and
> > call the functions you do at at the cost of portability
>
> Again, no ANSI C violation. If you include a nonstandard header, you're
> invoking undefined behaviour.
Undefined or implementation defined ?
> This "problem" is common to all C
> implementations I've ever heard of, because all of them provide
> nonstandard headers, besides the standard ones.
The specific and typical problems I had in mind is on the one hand
the set of special ConsoleApp functions that Microsoft provides
and OTOH that you can call all Windows functions from a concole
application. Its really something like a Windows app in disguise :-)
To summarize: I thought I'd try to give a prospective Visual-C
user a hand and tell him to be careful. He seemed to hold the opinion
that using Visual-C will sortof automatically result in ANSI-C
source code. That is of course a dangerous assumption.
Jack Klein
> In article <3609EB...@CWA.de>, Stephan Wilms <Stepha...@CWA.de> wrote:
> >"Console Applications" in Visual-C are indeed a good way to write
> >ANSI-C code. But you must be careful in some cases, because even
> >the strict ANSI-C mode does not catch a number of ANSI-C violations,
> >for instance:
> > - "void main" is accepted without warning
> > - "//" comments are accepted without warning
>
> That's only if you fail to give the Microsoft compiler the /Za option
> which disables non-conforming extensions, such as // comments and other
> things, and causes the compiler to emit ANSI C required diagnostics.
>
> If you want to do ANSI C programming under Windows, it's advisable to use /Za.
>
> The Microsoft /Za option is roughly analogous to -ansi -pedantic under GCC.
<Jack>
The damn shame is that there is no check box setting for this. You have to
know what it means and manually edit the compiler command line box.
</Jack>
Ken Nicolson
wrote:
I don't know what version you're running, but there's a check box in
v5 (and v4 IIRC) under Settings/"C/C++"/Customize/Disable language
extensions. Pull up the online help for /Za and it even tells you this
is the location.
></Jack>
Ken
Lawrence Kirby
...
>> Again, no ANSI C violation. If you include a nonstandard header, you're
>> invoking undefined behaviour.
>
>Undefined or implementation defined ?
Both. :-)
The immediate action that the implementation must perform (more specifically
its search strategy) is implementation-defined. However the important thing
as far as the program is concerned is what effect the inclusion will have
on the program. If a standard header is included the standard itself
specifies the effect. If a non-standard header is included the contents and
effect of that header are unknownand this results in undefined behaviour,
*unless* the contents of the header are specified as part of the program
definition. So if foo.c includes foo.h and foo.h is part of the program
source there is no problem. But if you include a non-standard headers
supplied by the implementation the behaviour of the *program* is undefined
as far as standard C is concerned.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
tst...@my-dejanews.com
fr...@genesis.demon.co.uk wrote:
> In article <360B38...@CWA.de> Stepha...@CWA.de "Stephan Wilms"
writes:
>
> ...
>
> >> Again, no ANSI C violation. If you include a nonstandard header, you're
> >> invoking undefined behaviour.
> >
> >Undefined or implementation defined ?
>
> Both. :-)
>
> The immediate action that the implementation must perform (more specifically
> its search strategy) is implementation-defined. However the important thing
> as far as the program is concerned is what effect the inclusion will have
> on the program. If a standard header is included the standard itself
Um, doesn't including <limits.h> actually produce implementation defined
behaviour (including standard headers that define EOF, BUFSIZ, size_t, ...,
too).
[snip]
--
Tristan Styles
Failure is not an option
It is Standard Operating Procedure
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
Michael Rubenstein
>In article <906859...@genesis.demon.co.uk>,
> fr...@genesis.demon.co.uk wrote:
>> In article <360B38...@CWA.de> Stepha...@CWA.de "Stephan Wilms"
>writes:
>>
>> ...
>>
>> >> Again, no ANSI C violation. If you include a nonstandard header, you're
>> >> invoking undefined behaviour.
>> >
>> >Undefined or implementation defined ?
>>
>> Both. :-)
>>
>> The immediate action that the implementation must perform (more specifically
>> its search strategy) is implementation-defined. However the important thing
>> as far as the program is concerned is what effect the inclusion will have
>> on the program. If a standard header is included the standard itself
>> specifies the effect. ...
>
>Um, doesn't including <limits.h> actually produce implementation defined
>behaviour (including standard headers that define EOF, BUFSIZ, size_t, ...,
>too).
>
>[snip]
No. Using the various definitions in <limits.h> is likely to produce
implementation-defined behavior, but not necessarily. Just including
<limits.h> does not. For example, the behavior of the following is
defined by the standard:
#include <limits.h>
#include <stdio.h>
int main(void)
{
if (INT_MAX > 1)
puts("conforming");
return 0;
}
--
Michael M Rubenstein
Lawrence Kirby
>In article <906859...@genesis.demon.co.uk>,
> fr...@genesis.demon.co.uk wrote:
>> In article <360B38...@CWA.de> Stepha...@CWA.de "Stephan Wilms"
>writes:
>>
>> ...
>>
>> >> Again, no ANSI C violation. If you include a nonstandard header, you're
>> >> invoking undefined behaviour.
>> >
>> >Undefined or implementation defined ?
>>
>> Both. :-)
>>
>> The immediate action that the implementation must perform (more specifically
>> its search strategy) is implementation-defined. However the important thing
>> as far as the program is concerned is what effect the inclusion will have
>> on the program. If a standard header is included the standard itself
>> specifies the effect. ...
>
>Um, doesn't including <limits.h> actually produce implementation defined
>behaviour (including standard headers that define EOF, BUFSIZ, size_t, ...,
>too).
The answer is no, but this is nevertheless an excellent question. Consider
a simple program
#include <limits.h>
int main(void)
{
return 0;
}
Does the inclusion of <limits.h> affect in any way the behaviour of the
program? The answer is of course no. Is there anything in the program
code that explicitly invokes implementation-defined behaviour? Again,
there isn't. #include does specify an implementation-defined search
strategy but for a standard header the result is not implementation-defined,
it must always find the appropriate standard header for that
implementation.
This is mainly a terminology thing. The term implementation-defined doesn't
apply to everything that is implementation-specific, it only applies
to things that the standard labels explicitly as implementation-defined.
So the *only* way to see whether something is implementation-defined
is to look in the standard and see if it labels it as such. If the
standard made the inclusion of standard headers implementation-defined
then strictly conforming programs couldn't include them which would
be unfortunate.