C portability is a myth

[infobahn]

Yes, but... At least on GNU/Linux, if you consult the man page for
any given "C" function, you are given clear information on whether
it is ISO C, POSIX, BSD or something else. I think that is less
clear in the Windows world.

http://tinyurl.com/3m424 (MSDN page on compatibility)

Also, every[1] C function listed in MSDN has a compatibility section
which gives clear information on the matter.
There are lots of reasons to bash MS. This isn't one of them.
[1] No, of course I didn't. Would you have done? I just looked at
one, actually.

A coupla quotes From MSDN:

<quote>

malloc

Allocates memory blocks.

void *malloc( size_t size );
Routine Required Header Compatibility
malloc <stdlib.h> and <malloc.h> ANSI, Win 95, Win NT
^^^^^^^^

Yes, that's an error from ANSI's (and ISO's) point of view. So what?
The compatibility information you asked for is there.

</quote>

<quote>

double sin( double x );

[snip]

Example

/* SINCOS.C: This program displays the sine, hyperbolic
* sine, cosine, and hyperbolic cosine of pi / 2.
*/

#include <math.h>
#include <stdio.h>

void main( void )
{

</quote>

I rest my case.

Here is your proposition again:

"Yes, but... At least on GNU/Linux, if you consult the man page
for any given "C" function, you are given clear information on
whether it is ISO C, POSIX, BSD or something else. I think that
is less clear in the Windows world."

You quoted two examples, malloc and sin, to support your case. In
neither case did you demonstrate that the compatibility information
is unclear or missing. Yes, the MS documentation has mistakes, and
indeed some of them betray ludicrous ignorance of the language. But
that wasn't the basis of your original claim, which was about lack
of, or lack of clarity in, compatibility information in their docs.

 

[Richard Bos]

Here is your proposition again:

"Yes, but... At least on GNU/Linux, if you consult the man page
for any given "C" function, you are given clear information on
whether it is ISO C, POSIX, BSD or something else. I think that
is less clear in the Windows world."

You quoted two examples, malloc and sin, to support your case. In
neither case did you demonstrate that the compatibility information
is unclear or missing. Yes, the MS documentation has mistakes, and
indeed some of them betray ludicrous ignorance of the language.

Yup. And this _is_ the problem. Since MS show such ignorance of (or,
more probably, disinterest in) the Standard, they can simply not be
trusted on any other aspects of it, either. Such errors make any claims
concerning ISO C on MSDN mere data, not information.

Richard

 

[Allin Cottrell]

infobahn wrote -- in re. my attempt to support my case that
a programmer on the MS Windows platform, relying upon the
documentation provided in connection with that platform,
would be likely (more likely than users of certain other
platforms) to get the wrong idea about what is and what is
not ISO standard C:

You quoted two examples, malloc and sin, to support your case.

They were the first two to come to hand, in a few minutes' browsing
of MSDN. I'm confident they could be multiplied many times.

In neither case did you demonstrate that the compatibility
> information is unclear or missing.

Dammit, I showed that it was plain _wrong_. Is that not
enough?

Allin Cottrell

 

[Randy Howard]

Dammit, I showed that it was plain _wrong_. Is that not
enough?

When the ISO standard is available for $18, and man pages
for all the functions are available in hundreds of places
on the web for free, what exactly is so difficult about
writing standard C on a Windows box?

 

[Mark McIntyre]

infobahn wrote


Dammit, I showed that it was plain _wrong_. Is that not
enough?

In what way is the information that malloc is ANSI compatible wrong? Please
explain.

 

[Keith Thompson]

In what way is the information that malloc is ANSI compatible wrong? Please
explain.

I think it's about the mention of the <malloc.h> header.

 

[Allin Cottrell]

I think it's about the mention of the <malloc.h> header.

It is indeed. The implication of the MSDN page is that <malloc.h>
is a standard C header. I have not found such misinformation in
*nix man pages for functions such as malloc().

Allin Cottrell

 

[infobahn]

It is indeed. The implication of the MSDN page is that <malloc.h>
is a standard C header. I have not found such misinformation in
*nix man pages for functions such as malloc().

man system

DESCRIPTION

system() executes a command specified in string by calling /bin/sh -c
string, and returns after the command has been completed. During exe-
cution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT
will be ignored.

RETURN VALUE

The value returned is -1 on error (e.g. fork failed), and the return
status of the command otherwise. This latter return status is in the
format specified in wait(2). Thus, the exit code of the command will
be WEXITSTATUS(status). In case /bin/sh could not be executed, the
exit status will be that of a command that does exit(127).

CONFORMING TO
ANSI C, POSIX.2, BSD 4.3
(etc)

The implication of the man page is that /bin/sh -c, SIGCHLD, SIGQUIT,
wait, WEXITSTATUS, and the semantics of the return status, are all
defined by ANSI.

Neither MSDN nor man pages define C. They can, however, be used as
a quick reference by those who have a firm grasp of the language
already. I can read the above descriptions of malloc and system,
and get what I need from them (in the unlikely event that I might
have forgotten), without being confused by what you call misinform-
ation. So can you, I'm sure.

Those who can't should be learning C from a good C book, not from
man pages or MSDN.

 

[Randy Howard]

RETURN VALUE

The value returned is -1 on error (e.g. fork failed), and the return
status of the command otherwise. This latter return status is in the
format specified in wait(2). Thus, the exit code of the command will
be WEXITSTATUS(status). In case /bin/sh could not be executed, the
exit status will be that of a command that does exit(127).

CONFORMING TO
ANSI C, POSIX.2, BSD 4.3
(etc)

The implication of the man page is that /bin/sh -c, SIGCHLD, SIGQUIT,
wait, WEXITSTATUS, and the semantics of the return status, are all
defined by ANSI.

Not to mention fork(). I knew somebody would find a man page
showing the other side. What I am surprised by is the way the
role of the usual MS bashers and Linux bashers seem to be
reversed in this.

 

[infobahn]

I knew somebody would find a man page
showing the other side. What I am surprised by is the way the
role of the usual MS bashers and Linux bashers seem to be
reversed in this.

As I think I mentioned before, I have no problem with MS-bashing
where MS-bashing is due, and heaven knows there are enough occasions
for that! But MS-bashing for MS-bashing's sake should be reserved
for recreational use only.

 

[Mark McIntyre]

It is indeed. The implication of the MSDN page is that <malloc.h>
is a standard C header.

There's no such implication at all. But you're entitled to your pedantry
even if it /is/ childish. The point is, the MSDN clearly states that
malloc() is ANSI.

I have not found such misinformation in
*nix man pages for functions such as malloc().

Then you need to learn to read manpages better.

 

[Keith Thompson]

There's no such implication at all. But you're entitled to your pedantry
even if it /is/ childish. The point is, the MSDN clearly states that
malloc() is ANSI.

There doesn't appear to be any implication that <malloc.h> is *not* a
standard C header.

Here's the MSDN documentation, as quoted upthread by Allin Cottrell:

] malloc
]
] Allocates memory blocks.
]
] void *malloc( size_t size );
] Routine Required Header Compatibility
] malloc <stdlib.h> and <malloc.h> ANSI, Win 95, Win NT

Yes, it says that the malloc() function is ANSI -- but if I didn't
know any better, reading just the quoted documentation, I'd certainly
assume that the <malloc.h> header is also ANSI. To look at it another
way, if ANSI/ISO C standard *did* define malloc() in both <stdlib.h>
and <malloc.h>, the quoted MSDN documentation wouldn't need to be
changed to reflect this.

Not that it really matters.

 

[Mark McIntyre]

There doesn't appear to be any implication that <malloc.h> is *not* a
standard C header.

Nor, for that matter, is there any indication that it /is/. Or indeed that
its *not* a flavour of cheese.

Lets remember, this is the manpage defining malloc(), not the header.

Yes, it says that the malloc() function is ANSI -- but if I didn't
know any better, reading just the quoted documentation, I'd certainly
assume that the <malloc.h> header is also ANSI.

IME most newbies have absolutely no clue that there even *are* standard
headers, let alone whether MS's documentation might suggest which ones they
are. So I'm suspicious of this idea, nay, more than suspicious.....

In any events, I read it as "the function, which is compatible with both
ANSI C and windows platform extensions, is defined in both malloc.h and
stdlib.h." Neither more nor less.

Perhaps thats because I already know that malloc.h isn't ANSI, or perhaps
I'm not searching the docs for examples of bad editing. Who can tell, as
the man in the hut said to his cat?

 

[Chris Torek]

In any events, I read [the quoted Microsoft documentation] as
"the function, which is compatible with both ANSI C and windows
platform extensions, is defined in both malloc.h and
stdlib.h." Neither more nor less.

For whatever it may be worth, given just the one snippet of
documentation quoted (however far back in the thread), and no
external knowledge of the C standards, I would have suspected that
it meant: "in order to get malloc() declared, you must include
*both* stdlib.h *and* malloc.h" (and presumably in that order).

This sort of requirement is not uncommon in POSIX systems, for
instance, where before one uses the "stat" family of functions,
one must include both <sys/types.h> and <sys/stat.h>, in that
order.