C, really portable?

[Netocrat]

Re: C, really portable?

On Sun, 11 Dec 2005 10:35:36 +0000, Mark McIntyre wrote:[color=blue]
> On Sun, 11 Dec 2005 01:44:43 +0100, in comp.lang.c , jacob navia
> <jacob@jacob.re mcomp.fr> wrote:
>[color=green]
>>There could be always provisions that allow certain parts of the
>>standard to be optional![/color]
>
> There's already quite a lot thats conditional on the implementation
> being able to support it, such as the entire IO library, the maths
> library, and so on.[/color]

You mean on a non-hosted implementation, right?

| 5.1.2.2.2 Program execution
| In a hosted environment, a program may use all the functions, macros,
| type definitions, and objects described in the library clause (clause 7).
[color=blue]
> I can think of no reason to further bloat an
> already massive document with a zillion pages entitled" this bit only
> applies if you're using Zarniwhoot C 3.6 on a MicroBeeble 5 with Snork
> 2.4 or lower OS".[/color]

You have a good point re reducing bloat.

Afaics general classes of errors for printf isn't a badly flawed
suggestion, so long as they are optional for an implementation. jacob's
claim that this would aid portable error analysis seems to be correct.

Whether this is useful enough to counter an argument of bloat minimisation
is debatable, but introducing an example that misrepresents jacob by
suggesting he intended implementation-specific wording is an inflammatory
way to go about that debate.

--

http://members.dodo.com.au/~netocrat

[Mark McIntyre]

Re: C, really portable?

On Sun, 11 Dec 2005 11:41:17 GMT, in comp.lang.c , Netocrat
<netocrat@dodo. com.au> wrote:
[color=blue]
>On Sun, 11 Dec 2005 10:35:36 +0000, Mark McIntyre wrote:[color=green]
>> On Sun, 11 Dec 2005 01:44:43 +0100, in comp.lang.c , jacob navia
>> <jacob@jacob.re mcomp.fr> wrote:
>>[color=darkred]
>>>There could be always provisions that allow certain parts of the
>>>standard to be optional![/color]
>>
>> There's already quite a lot thats conditional on the implementation
>> being able to support it, such as the entire IO library, the maths
>> library, and so on.[/color]
>
>You mean on a non-hosted implementation, right?[/color]

indeed.
[color=blue]
>Afaics general classes of errors for printf isn't a badly flawed
>suggestion, so long as they are optional for an implementation. jacob's
>claim that this would aid portable error analysis seems to be correct.[/color]

Well, obviously I'm unconvinced, especially since there /are/ ways to
check this. I'd personally rather see the *printf functions set errno,
and leave it to implementations of perror etc to turn that into
something meaningful.
[color=blue]
>Whether this is useful enough to counter an argument of bloat minimisation
>is debatable, but introducing an example that misrepresents jacob by
>suggesting he intended implementation-specific wording[/color]

My problem is that /I/ think thats what he /has/ suggested.
[color=blue]
>is an inflammatory way to go about that debate.[/color]

Unfortunately his way of presenting his POV is so assertive that it
brings out the worst in many people.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Malcolm]

Re: C, really portable?

"Mark McIntyre" <markmcintyre@s pamcop.net> wrote[color=blue]
>[color=green]
>>Please understand that I am NOT arguing against portability
>>but pointing to the fact that even in the most simple
>>programs, standard C leaves an essential part of
>>software construction: error analysis, completely out
>>of the picture![/color]
>
> Only if the programmer is bad.
>[/color]
No.
A lazy programmer like me says

int main(void)
{
printf("Hello world\n"):
return 0;
}

and says that if stdout isn't working, there are probably all sorts of other
problems, so just let sys admin fix them.

A superior programmer says

int main(void)
{
int err;
err = printf("Hello world\n");
if(err < 0)
{
fprintf(stderr, "Stdout not working\n");
exit(EXIT_FAILU RE);
}
return 0;
}

A super-duper top-notch programmer says

int main(void)
{
int err;
err = printf("Hello world\n");
if(err < 0)
{
printf_error_ro utine(err);
exit(EXIT_FAILU RE);
}
return 0;
}

/*
printf_error_ro utine.c
Any program, this platform only.
*/

/*
default implentation - comment in if porting
void printf_error_ro utine(int ec)
{
fprintf(stderr, "printf failed with error code %d\n", ec);
}
*/

void printf_error_ro utine(int ec)
{
switch(ec)
{
case EOF:
fprintf(stderr, "Error on stdout\n");
break;
/* etc */
}
}

As the programmer gets better, the code gets more unreadable, less portable,
less maintainable, and more prone to bugs.

[Malcolm]

Re: C, really portable?


<websnarf@gmail .com> wrote[color=blue][color=green][color=darkred]
>> >Remind me. You're the one that said empty strings are illegal right?[/color]
>>
>> No, I'm the one that said they made no sense to me.[/color]
>
> No, you said they were invalid:
>[/color]
Mark:[color=blue]
>Yes, I realise thats what he was trying to trap. I don't consider a
>string of length zero to be a valid string however. YMMV, as may
>Paul's.
>[/color]
C convention, which Mark obviously didn't appreciate, is that the empty
string should be accepted by string functions.
However there was no implication that such strings are illegal -i.e.
impossible to produce in a correct C program.

[Mark McIntyre]

Re: C, really portable?

On 11 Dec 2005 02:58:08 -0800, in comp.lang.c , websnarf@gmail. com
wrote:
[color=blue]
>Mark McIntyre wrote:[color=green]
>> On 10 Dec 2005 19:05:25 -0800, in comp.lang.c , websnarf@gmail. com
>> wrote:
>>[color=darkred]
>> >Remind me. You're the one that said empty strings are illegal right?[/color]
>>
>> No, I'm the one that said they made no sense to me.[/color]
>
>No, you said they were invalid:[/color]

which is not the same as illegal.

Perhaps you need to set your transporter to bring a copy of hte OED
over from Planet Earth so that when twisting other's words, you can be
twistier.

EOT.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[P.J. Plauger]

Re: C, really portable?

"Chuck F. " <cbfalconer@yah oo.com> wrote in message
news:7NydncVso8 fIWAbeRVn-tw@maineline.ne t...
[color=blue]
> P.J. Plauger wrote:[color=green]
>>[/color]
> ... snip ...[color=green]
>>
>> Please don't translate my qualitative measure into a Boolean.
>> Turn your contrast knob down a bit. My point was that you could
>> achieve rather high portability using the Pfort subset of Fortran.
>> (See Kernighan & Plauger, "Software Tools".) You could do not
>> quite as well with Pascal, even though that language was allegedly
>> more portable than Fortran. (See Kernighan & Plauger, "Software
>> Tools in Pascal".) But you can write *way* more powerful code
>> that's portable in C.[/color]
>
> The problem there was that most compiler systems of the time did not
> adhere to the standard, whether that standard was J & W, or the later ISO.
> Borland and UCSD were notably non-compliant. However C had the great
> advantage of more or less universal compliance with the C90 standard, or
> the earlier drafts.[/color]

1) Fortran66 was widely honored by the early 1970s, but you still
needed Pfort to avoid the non-portabilities inherent in the language.
And you still were limited by the universe of discourse of a tool
for translating math formulas into assembly language.

2) UCSD failed to standardize byte order, and failed to advertise
the fact, so it missed the boat on having machine-independent
binaries and surprised novices all the time.

3) The limitations of Pascal I encountered stemmed from an inherent
lack of expressiveness in the language definition -- the portable
subset was just too weak. (Brian Kernighan wrote a now famous
essay on the subject after we completed Software Tools in Pascal.)

4) Borland, in fact, *saved* Pascal by turning it into a reasonably
powerful language. Too bad the Pascal Standard chose to rubber
stamp Wirth's test-tube implementation. But even Borland Pascal
is not as flexible a language as C.

5) I was writing, and selling, highly portable products in C long
before the C Standard was completed. And I was not alone.

6) C90 had more or less universal compliance from the get-go
because X3J11 attracted most of the dozens of C compiler
implementers. And we honored the past practices of the C
community way better than most other language committees.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Flash Gordon]

Re: C, really portable?

websnarf@gmail. com wrote:[color=blue]
> P.J. Plauger wrote:[color=green]
>> <websnarf@gmail .com> wrote in message
>> news:1134269715 .256741.230330@ f14g2000cwb.goo glegroups.com.. .[color=darkred]
>>>>> Thats nice, but not the question OP was asking. Please crack open a
>>>>> dictionary: Availability != Portability.
>>>> No, but it's part of a complete breakfast. Portability is a
>>>> measure of the relative cost of moving software between
>>>> platforms vs. rewriting it;
>>> Incorrect. If what you said was true then "portabilit y cost" would be
>>> a redundant phrase that had no meaning. Of course, that's not the
>>> case. So you are attempting to claim that the definition of
>>> "portabilit y" is really the definition of "portabilit y cost".[/color]
>> Call it a claim if you will. I think of it as an observation.[/color]
>
> That's pretty slithery ...
>[color=green]
>> If you reread your earlier diatribes, you'll find nearly as many
>> potential meanings for "portabilit y" as occurrences of that word.[/color]
>
> That would be pretty hard considering I've cited the dictionary
> definition before as well.[/color]

http://www.sei.cmu.edu/str/indexes/glossary/portability.html

| Portability
| the ease with which a system or component can be transferred from
| one hardware or software environment to another [IEEE 90].

http://www.answers.com/main/ntquery;jsessionid=3tu9ngjnl23qn?tname=portable&method=6&sbid=lc04a

| por·ta·ble (pôr'tə-bəl, pōr'-)
| adj.
| 3. Computer Science. Relating to or being software that can run on
| two or more kinds of computers or with two or more kinds of
| operating systems.

Tell me how you transfer to hardware (or a kind of computer) where the
language is not available and I'll accept that availability of the
language for targets is not part of portability.
[color=blue][color=green]
>> I'm simply coming from a coherent worldview that seems to fit
>> with what rational people seem to mean when they use that word.[/color]
>
> And you've come to the conclusion that C is a portable language out of
> that. Some might say there's something wrong with your worldview.[/color]

Some might say the world is flat, does that make it true?
[color=blue][color=green]
>> I've been promulgating this "definition " for decades,[/color]
>
> That's pretty sad ... Its like the swiftboat veterans who believe we
> could have won in Vietnam if we had just stayed there.
>[color=green]
>> [...] and I've repeatedly been told that it makes sense.[/color]
>
> By who? Oh yes -- people in your worldview.[/color]

Well, people who disagree would hardly be telling him that he is
correct. I tend to agree with P.J. Plauger BTW.

<snip>
[color=blue][color=green][color=darkred]
>>>> Please don't translate my qualitative measure into a Boolean.
>>>> Turn your contrast knob down a bit. My point was that you could
>>>> achieve rather high portability using the Pfort subset of Fortran.
>>> Right, but the same true of other languages including C, and is
>>> actually not in support of your point.[/color]
>> Back to the complete breakfast again. That "characteristic " you
>> call portability has a number of components. Among them are
>> availability, uniformity, and power.[/color]
>
> No -- these are orthogonal concepts. The Hello world program is plenty
> portable, but you wouldn't call it powerful. The fact that certain
> platforms don't have C compilers, (affecting availability), doesn't
> make the program itself non-portable.[/color]

It reduces the portability though, because it is a "hardware or software
environment" to which it cannot be transfered.
[color=blue]
> Similarly, you can look at the source code for Berkeley Db. Its
> definately very powerful, and its got pretty reasonable availability,
> and the high level API is very uniform -- but just take a look at the
> source code! Its pathetic! Hand ported to each and every platform
> one at a time, with only the very highest level of API portability![/color]

The bulk of hte code is NOT CHANGED for each platform. As is generally
the case, they isolate the platform dependant areas of the code.

http://www.sleepycat.com/docs/ref/distrib/port.html

[color=blue]
> What does the mean? It means we *KNOW* it doesn't work on Itanium or
> AMD64 platforms -- or at least we know it won't until it gets
> painstakingly hand ported to those platforms. The upshot? BerkeleyDB
> is inherently unportable, excepting for the fact that it has been
> "ported by force" to a finite (though fairly large) number of
> platforms.[/color]

The bulk of the code is very portable, it is only a relatively small
portion of the code that needs to be ported.
[color=blue][color=green]
>> [...] C rates high on all these measures, making it IME the best candidate in many
>> cases for writing code intended to be portable.[/color]
>
> Nonsense. For anything except the most trivial code, you put real
> effort into porting C code,[/color]

Strange that I've ported real code that solved a complex problem with
absolutely no effort in the past. When I say no effort, I mean I copied
it on to a completely different system (a workstation instead of an
embedded DSP processor) wrote some test harnesses and debugged it on the
workstation. I then recompiled for the DSP and it worked with no further
changes, which was a great relief as I did not have decent debugging
tools for the DSP.
[color=blue]
> and even when you do so, your best bet is
> to stick with very conservative statements like "Its very portable, and
> known to work on platforms X, Y, Z ..." when describing such
> portability. The C specification covers non-2s complement, undefined
> behavior on integer overflow, incorrect right shifting, etc but the
> problem is that such platforms are barely available, so you can't test,
> and so you can't be sure.[/color]

As has been stated, portability is not a boolean. In any case, I know
Java applications that won't run on SCO 5.0.4 running on a standard x86
based system. The same Java application will run on the same hardware if
you put a different OS on, specifically we have had customers upgrade to
SCO 5.0.7 to solve the problem without changing the HW. Java *is*
available for SCO 5.0.4, just not the right version. So even if you
write a Java application you don't know it will run on the specific OS
even if it runs on the specific HW.

<snip>
[color=blue]
> Show me run-time generated code, autoserialized data structures or
> coroutines in C.[/color]

I've got an interpreter written in standard C that allows me to run
run-time generated code within a C application. It does not let me do
everything, but it does allow one of the things you've asked for. I'm
sure many others have similar things.
[color=blue][color=green][color=darkred]
>>>>> the entire job of portability up to the actual developer of the code,
>>>>> well then in fact *MOST* languages are portable.
>>>> Your contrast knob is set too high again. The developer always
>>>> has *some* responsibility in writing portable code; the question
>>>> is what reward you get for your effort. I maintain that Standard
>>>> C has a pretty high reward for remarkably low effort,
>>> Right, because performance doesn't matter to you, and things like
>>> cryptography just have no meaning to you.[/color]
>> Where the hell did that come from?[/color]
>
> Painful experience. If you can't right shift deterministical ly, you've[/color]

You can right shift deterministical ly if you use unsigned integer types.
[color=blue]
> lost performance. If you can't assume integer size, you've lost[/color]

Use the int_least types and mask down (or if using C89 a type guaranteed
to be large enough), any decent compiler will eliminate the mask if the
type was the exact size required.
[color=blue]
> performance. Standard cryptographic algorithms require exact scalar
> integer size knowledge (have "at least" such and such many bits is not
> helpful -- it needs to be exact), deterministic right shifting,[/color]

See comments above.
[color=blue]
> no
> integer overflow,[/color]

Use unsigned integer types and that's done, assuming you want the result
to wrap (which I think you do) rather than limiting (which some
processors can do).
[color=blue]
> and double-wide integer multiply.[/color]

You cast to a large enough unsigned integer type, unless you are going
beyond the largest integer type guaranteed to be available. Since you've
not said how large a "double-wide" is we can't tell.
[color=blue]
> If you are forced
> to emulate those operations (which the ANSI C standard requires, if you
> are writing such code), your performance drops.[/color]

See comments above. Mainly use unsigned types.
[color=blue][color=green]
>> [...] And who the hell are you to tell
>> me what matters to me or what has meaning to me? Get stuffed.[/color]
>
> If you try to implement high performance code, especially crypto, with
> just standard C how do you expect to do so with "remarkably low
> effort"? You'll end up giving up on one of those things.[/color]

You think using an interpreted language does not have an impact on
performance? Or a language that forces the compiler to jump through
various hoops to implement the semantics you've decided on?
[color=blue][color=green][color=darkred]
>>> And of course, for whatever
>>> reason you are not actually comparing it to other contemporary
>>> languages.[/color]
>> Funny, I thought I was.[/color]
>
> You see, a lot of people are using google to read usenet now. It means
> people can literally check your statements with the click of the mouse.
> You can't rely on the news servers expiring your articles in hopes
> that nobody will check what you say. In posts leading up to this one,
> you've mentioned Fortran and Pascal -- this is in a response to my
> statements about "modern languages in common use".[/color]

Well, I've mentioned Java.
[color=blue][color=green][color=darkred]
>>>> [...] If you take too much pain in porting the code,
>>>> somewhere along the line the cost of a complete rewrite
>>>> proves to be lower and the code is "not portable". (You
>>>> sometimes find that out too late.)
>>> Now tell me who's being black and white?[/color]
>> If the cost is $17,000, that's a "degree".[/color]
>
> No, that's a *MEASURE*. Measures, like cost, can go to infinity (in
> theory). Degrees, as it is meant here, basically is between 0% and
> 100% (between 0 and 360 if you are talking about a circle, but its the
> same idea). Do you see the difference?[/color]

I've dealt with hardware that had a movement range of greater than 360
degrees. In any case, you can scale cost in to a 0% to 100% range using
a non-linear scale such that 0% portable is infinite cost and 100% is 0
cost if that is what you want.
[color=blue][color=green]
>> If the question is
>> "Is cost less than $17,000?" that's a Boolean. Black and white.[/color]
>
> Ok, but you miss my point. Why is it ok for *you* to synthesize an
> arbitrary black and white,[/color]

He did not. He just showed the difference.
[color=blue]
> but when I just cite a commonly accepted
> black and white (source code being portable or not), you get to deride
> me for it?[/color]

I don't know of anyone other than you that considers portability to be a
black or white issue.
[color=blue][color=green][color=darkred]
>>> Each of those languages was *painstakingly ported*. As posted by
>>> Walter Robinson in this thread, apparently the Perl source code (which
>>> is in C) is a horrendous mess to port to each platform.[/color]
>> Shows what happens when you believe more in Perl than in C, I'd say.[/color]
>
> But the problems, in the case, *came* from C, the language it was
> implemented in. Once its up and running, presumably, he'll have the
> portable Perl language ready for him to use.[/color]

Apart from the fact that it was stated that once you have perl up and
running not all programs written in pure perl will actually run on it
for the simple reason that not all features that are part of perl on one
target are part of perl on another target, and perl is defined as being
that which is implemented as perl on the specific target of interest.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Eric Sosman]

Re: C, really portable?

Keith Thompson wrote:[color=blue]
> Eric Sosman <esosman@acm-dot-org.invalid> writes:
>[color=green]
>>jacob navia wrote:[/color]
>
> [...]
>[color=green][color=darkred]
>>>The result of printf is negative if there was an error,
>>>but the exact values are implementation specific and
>>>will change from this implementation of printf to the
>>>next one. This makes impossible any error analysis
>>>of that function call in a portable way.[/color]
>>
>> Nonsense. <stdio.h> defines a macro named EOF, and
>>the expansion of that macro is the negative value you
>>mention. You can portably compare `r' to EOF and make
>>decisions based on equality or inequality. In this case
>>you can even forego EOF altogether and just test `r<0'
>>to see whether an error has occurred.[/color]
>
>
> No, the standard says:
>
> The fprintf function returns the number of characters transmitted,
> or a negative value if an output or encoding error occurred.
>
> There's no implication that the negative value is the same as EOF.[/color]

You're right; my error. (Portably detected ;-) The
`r<0' test still works just fine, though.

--
Eric Sosman
esosman@acm-dot-org.invalid

[P.J. Plauger]

Re: C, really portable?

<websnarf@gmail .com> wrote in message
news:1134284425 .765718.104640@ f14g2000cwb.goo glegroups.com.. .
[color=blue]
> P.J. Plauger wrote:[color=green]
>> <websnarf@gmail .com> wrote in message
>> news:1134269715 .256741.230330@ f14g2000cwb.goo glegroups.com.. .[color=darkred]
>> >> > Thats nice, but not the question OP was asking. Please crack open a
>> >> > dictionary: Availability != Portability.
>> >>
>> >> No, but it's part of a complete breakfast. Portability is a
>> >> measure of the relative cost of moving software between
>> >> platforms vs. rewriting it;
>> >
>> > Incorrect. If what you said was true then "portabilit y cost" would be
>> > a redundant phrase that had no meaning. Of course, that's not the
>> > case. So you are attempting to claim that the definition of
>> > "portabilit y" is really the definition of "portabilit y cost".[/color]
>>
>> Call it a claim if you will. I think of it as an observation.[/color]
>
> That's pretty slithery ...[/color]

No, it's an honest statement. The fact is that the meaning of
words comes out of popular usage. (See the OED.) If a dictionary
definition is demonstrably incorrect or incomplete, it behooves
you to clarify what is actually meant in common parlance. You
can't think or communicate clearly until you have a sharp,
shared meaning for the words you use to describe critical concepts.
[color=blue][color=green]
>> If you reread your earlier diatribes, you'll find nearly as many
>> potential meanings for "portabilit y" as occurrences of that word.[/color]
>
> That would be pretty hard considering I've cited the dictionary
> definition before as well.[/color]

Okay, you asked for it. I'll deal with the rest of your posting
separately (if the mood strikes me). Let's look at your self
proclaimed integrity vis a vis dictionary definitions.

I chased your links:

http://www.m-w.com/dictionary/portable

http://www.thefreedictionary.com/portable

http://dictionary.reference.com/search?q=portable

and found two distinct definitions of "portable" related to
computing:

Merriam-Webster:

1b: usable on many computers without modification <portable software>

American Heritage Dictionary:

3: Computer Science. Relating to or being software that can run on
two or more kinds of computers or with two or more kinds of operating
systems.

So it's clear that the dictionary definitions confine themselves
to *software*. Thus, the OP's elliptical question, "C, really
portable?" is nonsense. C is not software, but a programming
language. Nevertheless, you initially joined in the nonsense:

: pemo wrote:
: > Is C really portable?
:
: No. The standard embodies a portable syntax which exists as subset of
: any compliant compiler, but that's exactly as meaningless as you might
: suspect it is. For example, I don't believe there exists any pair of C
: compilers from different vendors that have exact source space
: compatibility.

So you begin by applying your beloved definition(s) to something
they were never intended to cover. And you go on in that vein
for several paragraphs.

Then the subject matter shifts:

: > I don't write portable C code [...]
:
: (well practically nobody does so ...)

You're now discussing portability in the dictionary sense,
but you're uttering demonstrable nonsense. In a *practical*
sense, *quite a few* people write portable code. Just look
around you.

After a few more paragraphs on this theme, the discussion
shifts again:

: > Conclusion: Whilst the language is portable, applications are not.
:
: A subset of the *syntax* is portable. Nothing more.

Now you're applying the concept of portability to syntax.
Nothing about that in any of your dictionaries, so once
again you're talking nonsense, but of a different flavor.

Then, in your first reply to me you said:

: > Before C came along, I was doing similar things with Fortran,
: > and with reasonable success.
:
: Well yeah, and you could do the same thing with Visual Basic, and the
: various Basic interpretors available for UNIXs, and so on. If you push
: the entire job of portability up to the actual developer of the code,
: well then in fact *MOST* languages are portable. If fact, did you know
: its fact possible to be portable *BETWEEN* many languages? When you
: put the onus onto the programmer, you can claim all sorts of
: capabilities for your language.

Now, portability is a "job" for the programmer. Or wait,
it's back to being an attribute of a language. No, it's
a thing that can exist *BETWEEN* (emphasis yours) many
languages. The dictionaries are receding at the speed of
light.

But we're not done yet. In the next paragraph, you say:

: There is a subtle difference between a language begin portable, and
: software which has been painstakingly ported.

Now we see yet another concept -- "porting" is something that's
*done* to programs. Not in your dictionaries, which insist that
portability comes "without modification". No pains there.

Then, a few posts later, we find you saying:

: Portability describes a *CHARACTERISTIC * of the degree of
: transportabilit y of source code. By itself, its not a measure of cost.

Now you're talking about a "degree of transportabilit y",
but neither of your beloved dictionary definitions treats
"portable" as anything other than a Boolean attribute.

And then:

: > [...] it's not a Boolean. Availability is thus an important
: factor in improving portability.
:
: No. Availability affects where you can port to. The nature of a given
: source code's portability is always taken against the set of platforms
: that have a compiler for that platform.

Now code is portable only if there's a compiler for a given
platform. Where does it say that in any dictionary?
(It's also not necessarily true.)

And then we come to:

: > Only if you think in black and white. We informally say that
: > a language is portable if it lowers the cost of writing
: > programs that are portable (cheaper to move than to completely
: > rewrite).
:
: Well no, *you* informally say that, because you have little respect for
: precise language. Its a good thing you aren't on any committee that
: manages a international standard. Oh wait ...

First you deny that you're using portability in a popular,
but non-dictionary sense, when you clearly are. Then you
accuse *me* of being imprecise, even though I was careful
to say what I meant and you were, shall we say, haphazard
at best. Then you fall back on insults, the last refuge of
the rhetorically challenged.

But then you say:

: http://www.m-w.com/dictionary/portable
: http://www.thefreedictionary.com/portable
: http://dictionary.reference.com/search?q=portable
:
: There's nothing about cost in any of those definitions. Also notice
: that the definitions include the "two or more platforms" in them.
: Meaning that "portabilit y" is not related to the number of platforms
: your code is portable, but rather the degree to which the software
: itself is inherently portable.

After brushing up on the definitions, you immediately say
portability is not related to the number of platforms
your code is portable, which directly contradicts the
previous sentence. And then you introduce the concept
of "degree of inherent portability" which is *not* in
the dictionary and *not* precisely any of the things
you said earlier.

So please don't lecture me on the proper use of dictionaries,
or precision in communication. And watch who you're calling
slithery. If the snake skin fits...

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Emmanuel Delahaye]

Re: C, really portable?

jacob navia a écrit :[color=blue]
> Is a program just using printf portable?
> For instance this one:
>
> #include <stdio.h>
> int main(void)
> {
> int r=printf("hello world\n");
> }
>
> Is not portable.[/color]

It is.[color=blue]
>
> Why?
>
> The result of printf is negative if there was an error,[/color]

So what ? You don't even read r in your code.

What about

if (r < 0)
{
perror ("stdout);"
}

Sounds very portable to me.

--
A+

Emmanuel Delahaye

[Emmanuel Delahaye]

Re: C, really portable?

jacob navia a écrit :[color=blue]
> This is just polemic. My message was clear: the error analysis of
> a printf call is not portable.
>
> printf ("%07L\n",23.78 );
>
> how do I detect the format error in my program without
> tying me to a specific printf implementation? ??[/color]

Maybe you should try a better compiler :

Compiling: main.c
main.c: In function `main_':
main.c:10: warning: unknown conversion type character 0xa in format
main.c:10: warning: too many arguments for format

--
A+

Emmanuel Delahaye

[Emmanuel Delahaye]

Re: C, really portable?

jacob navia a écrit :[color=blue]
> Is this code snippet portable?
>
> int a,b,c;
> ...
> a = b+c;[/color]

no, because b and c are not initialized. The behaviour is undefined.

--
A+

Emmanuel Delahaye

[Eric Sosman]

Re: C, really portable?

Mark McIntyre wrote:
[color=blue]
> On Sun, 11 Dec 2005 00:07:25 +0100, in comp.lang.c , jacob navia
> <jacob@jacob.re mcomp.fr> wrote:
>
>[color=green]
>>If you are satisfied with such an error analysis OK.
>>It *could* be that you need to know MORE isn't it?
>>
>>WHAT type of error?[/color]
>
>
> And how could such error analysis be portable?
>
>[color=green]
>>Input output error? (disk full, i/o whatever)[/color]
>
>
> Lets go on: Which sort of IO error? What caused it? Who was running
> the programme at the time? How much memory was in use? How many
> diskdrives were busy? Which horse running in the 3:30 at Kempton? You
> see my point?[/color]

Aha! So THAT's what's bothering you? You want a
distinct, documented code for every detectable error
condition?

Try the exercise of composing a list of all possible I/O
error conditions. If you make an honest attempt, I'm sure
you'll find the list unmanageably long. If you don't find
it so and have the intestinal fortitude to post your complete
list, I'm equally sure there will be no shortage of people
ready to pounce and point out error conditions you omitted.
Consider, too, that new I/O devices with new failure modes
are being invented all the time: the list will not remain
static.

The only way to keep the list to a manageable length is
to group multiple error conditions together -- and as soon
as you do so, of course, you're suppressing information
about the "root cause" error. You keep mentioning a "disk
full" error -- but is that really the root cause? No, the
disk actually has plenty of room but your account has reached
its quota. Even that isn't the ultimate cause, because the
I/O system automatically contacted the billing system to see
if it could purchase some more quota for you on the fly, and
the ultimate I/O error is "Credit card rejected."

Should the C Standard document a special printf() return
value for "Credit card rejected?"

Withdrawing from the verge of the ridiculous (but only
from the verge; think of buzz-phrases like "grid computing"),
let's get back to what your program would DO with this rich
source of information. As things stand today, all you learn
is that the printf() operation failed. If you're checking for
the failure (which you should, if your program is a "filter"
or other such utility), what would your program do differently
if it could distinguish "disk full" from "SCSI bus failure"
from "NFS server not responding?" You're imagining, it seems,
something like

int r = printf("hello, world\n");
if (r < 0) {
switch (r) {
case IOERR_DISK_FULL : ...; break;
case IOERR_OVER_QUOT A: ...; break;
case IOERR_NETWORK_F AILED: ...; break;
case IOERR_DISK_FAIL ED: ...; break;
/* etc. */
}

What, exactly, would replace each set of ellipses, and how
would your handling of IOERR_BAD_MEMOR Y_PARITY differ from
IOERR_BLACKBERR Y_LOST_PATENT_F IGHT_AND_TERMIN ATED_SERVICE?

If you want to write hardware diagnostics in C, you can
(probably, and with suitable extensions) do it. But it's a
little extreme to require the ability to do so "portably."

--
Eric Sosman
esosman@acm-dot-org.invalid

[jacob navia]

Re: C, really portable?

Hi Eric

I am not saying that the standard should specify
all possible errors. I am only saying that certain RANGES
of error codes should be specified so that portable programs
could test for i/o errors. This is all the more evident in
fprintf:
r = fprintf(...);
if (r >= MIN_PRINTF_IOER ROR && r < MAX_PRINTF_IOER ROR ) {
// Error handling for i/o errors
}

That would be portable now you see?

if (r >= MIN_PRINTF_FORM AT_ERROR && r < MAX_PRINTF_FORM AT_ERROR)
// handle printf format errors

What do you DO now to test for fprintf errors?

Well, you have to code:
r = fprintf(....);
#ifdef LINUX
#ifdef TRIO_PRINTF
if (r == ...)
#elif GCC_PRINTF
if (r ==...)
#elif defined(WINDOWS )
#ifdef LCC_WIN32
if (r == ...)
#elif defined(WATCOM)
#elif defined (GCC)

#endif

etc etc, ad nauseum!

The standard would define a RANGE of values dedicated to specific errors
so that the calling program could determine what type of failure
happened, INDEPENDENTLY from the specific printf implementation.

[P.J. Plauger]

Re: C, really portable?

<websnarf@gmail .com> wrote in message
news:1134284425 .765718.104640@ f14g2000cwb.goo glegroups.com.. .

Now, where was I? I'll skip a few slurs and pick up with:
[color=blue][color=green][color=darkred]
>> > One can see this more clearly when one realizes that Java was a
>> > portable language *BEFORE* any compilers were available for it.
>> > Because that's the nature of the language itself. Availability, just
>> > provided proof.[/color]
>>
>> Uh, no. My brother worked a couple of years at making Java programs
>> really portable. He began by throwing away all multithreading code
>> and simplifying all GUI calls, so that he could then focus on all
>> the really sneaky portability problems. FWIW, he's one of the best
>> programmers I know, and it wasn't easy work for him. (Gosling
>> began by eliminating all the things from C that he *knew* were
>> portability problems, thus freeing himself up to get in *real*
>> trouble.)[/color]
>
> And so, if your brother were trying to port C code that was
> multithreaded and had GUI calls, do you think your brother would have
> an easier time?[/color]

Yep. He's done that too, for a couple of decades.
[color=blue]
> Your point here seems really irrelevant. Its true
> that race conditions are not portable and that Java has been going
> through growing pains, but I seem to remember a time when C was hardly
> in better shape ("far" and "near" anyone?) The main difference being
> that Java appears to have long ago solved problems that C never has.[/color]

Wait, is Java a modern language superior to C, or is it still
going through growing pains? The fact is, Java hit the deck
promising that even novices could write multithreaded code
that was safe and portable; after several revisions of the
underlying model, that's still not true. A popular dialect of
C (never standardized) used far and near pointers, to good
effect, to deal with a practical architectural issue. (They
even proved useful on a couple of non-X86 platforms as well.)
Whatever problems they caused pale compared to the races,
deadlocks, and sheer lack of portability inherent in Java
threading.

Java indeed "solved" a number of problems that C never has,
like flexible types and arithmetic representations . C hasn't
solved them because some of understand that they're not
problems.
[color=blue][color=green]
>> Back to the complete breakfast again. That "characteristic " you
>> call portability has a number of components. Among them are
>> availability, uniformity, and power.[/color]
>
> No -- these are orthogonal concepts. The Hello world program is plenty
> portable, but you wouldn't call it powerful.[/color]

Right. What I said was that portability has several components,
which I agree are orthogonal. I did *not* say that all portable
programs are powerful. You need to bone up on syllogisms.
[color=blue]
> The fact that certain
> platforms don't have C compilers, (affecting availability), doesn't
> make the program itself non-portable.[/color]

Right. What I said was that portability is not a Boolean, but a
quantity (cost, degree, whatever) measurable along several axes.
You've got your contrast knob turned up again (and your syllogizer
turned down, apparently).
[color=blue]
> Similarly, you can look at the source code for Berkeley Db. Its
> definately very powerful, and its got pretty reasonable availability,
> and the high level API is very uniform -- but just take a look at the
> source code! Its pathetic![/color]

Once again, power is not the only measure of portability,
or a synonym for it. Perhaps you should go back to Venn
diagrams and come forward once more.
[color=blue][color=green]
>> [...] C rates high on all these measures, making it IME the best
>> candidate in many
>> cases for writing code intended to be portable.[/color]
>
> Nonsense. For anything except the most trivial code, you put real
> effort into porting C code, and even when you do so, your best bet is
> to stick with very conservative statements like "Its very portable, and
> known to work on platforms X, Y, Z ..." when describing such
> portability.[/color]

Right. And that's exactly what you do with *every* program
that purports to be portable in the real world. Try telling
a project manager, "Don't bother to test the Java (or Perl,
or whatever) components before shipping -- they're guaranteed
to work on all supported platforms." Uh huh.

I agree that writing portable code takes effort, which is
why I often advise people not to aim for portability unless
they're really sure they'll actually do one or more ports.
Otherwise, you'll never recoup the investment. I simply
observe that when I do choose to invest in portable C code,
the extra cost is not that great for the reward in extra
usability/marketability.
[color=blue]
> The C specification covers non-2s complement, undefined
> behavior on integer overflow, incorrect right shifting, etc but the
> problem is that such platforms are barely available, so you can't test,
> and so you can't be sure.[/color]

Well, actually I've long since learned to avoid all those
gray areas you cite. We also tell our customers where we've
tested and where we haven't. We also develop test suites
for all our products, so a customer who wants to move our
stuff to a new platform faces a lower potential cost. And
we do exactly the same for our non-C products.
[color=blue][color=green][color=darkred]
>> > But you can write code far more powerful *still* in other languages,
>> > like Perl, Python, Java, etc.[/color]
>>
>> And that's where we part company. If by powerful you mean you can
>> perform certain large scale operations with an economy of expression,
>> then I agree.[/color]
>
> No, I mean things like ftp servers (its in the built-in libraries in
> Python),[/color]

Probably written in C, and callable from C. So you think a
programming language has to ship with a huge library to call
itself portable? I don't.
[color=blue]
> consistent numerics,[/color]

Having written numeric programs in multiple languages for over four
decades, I can assure you that the vast majority of portability
problems in that arena have next to nothing to do with the
consistency of numeric properties. A foolish consistency is,
in fact, a hindrance. (Think of Java and its pro-Sparc, anti
Pentium "consistent numerics".)

run-time generated code,

You mean like templates? Or generics? Or plain old macros?
[color=blue]
> auto-serialized
> data structures, threading, built-in array/string safety and memory
> leak protection and so on.[/color]

All of those are nice, and all of them are available in most of
the C compilers I use. Requiring them to be in the standard
library shipped with a language translator is, however, a
two-edged sword.
[color=blue][color=green]
>> [...] I write Maplesoft scripts to do things in minutes that
>> would be impractical in C. But if by powerful you mean that there
>> are few limitations on what you can manage, then C wins hands down.[/color]
>
> Show me run-time generated code, autoserialized data structures or
> coroutines in C.[/color]

And I've done all those things in C. When I have a problem that
needs one of those features, I'll often write the necessary piece
in a more suitable language (one that knows how to call all those
C functions already written for its runtime library). But sometimes
it's worth writing in C. And almost always the low-level magic
code and the glue code *has* to be written in C. I don't write
device drivers in Maplesoft.
[color=blue][color=green][color=darkred]
>> > Right, because performance doesn't matter to you, and things like
>> > cryptography just have no meaning to you.[/color]
>>
>> Where the hell did that come from?[/color]
>
> Painful experience. If you can't right shift deterministical ly, you've
> lost performance. If you can't assume integer size, you've lost
> performance. Standard cryptographic algorithms require exact scalar
> integer size knowledge (have "at least" such and such many bits is not
> helpful -- it needs to be exact), deterministic right shifting, no
> integer overflow, and double-wide integer multiply. If you are forced
> to emulate those operations (which the ANSI C standard requires, if you
> are writing such code), your performance drops.[/color]

Excuse me, but you made two statements about things that go on
inside my head. And you happen to be wrong. You're defending them
by stating opinions that come from inside *your* head. And I
happen to believe most of those opinions are not supported in
the real world. I am undisputably the world's foremost authority
on what goes on inside my head. You seem to have problems
distinguishing my reality from your personal reality from the
real world we both inhabit. I try not to.
[color=blue][color=green]
>> [...] And who the hell are you to tell
>> me what matters to me or what has meaning to me? Get stuffed.[/color]
>
> If you try to implement high performance code, especially crypto, with
> just standard C how do you expect to do so with "remarkably low
> effort"? You'll end up giving up on one of those things.[/color]

Even after my intentional vulgarism, you fail to note that
your presumptuous behavior is insulting. We are *not*
discussing whose view of the real world is superior. We're
talking about your inability to distinguish realities.
That's an awfully early developmental stage to get stuck at.
[color=blue][color=green][color=darkred]
>> > And of course, for whatever
>> > reason you are not actually comparing it to other contemporary
>> > languages.[/color]
>>
>> Funny, I thought I was.[/color]
>
> You see, a lot of people are using google to read usenet now. It means
> people can literally check your statements with the click of the mouse.
> You can't rely on the news servers expiring your articles in hopes
> that nobody will check what you say.[/color]

Why do you think I do? I have a long track record of standing
by what I say, and acknowledging errors when I (too often)
commit them.
[color=blue]
> In posts leading up to this one,
> you've mentioned Fortran and Pascal -- this is in a response to my
> statements about "modern languages in common use".[/color]

Right. But that's not the *only* thing I've said, by a
long shot. Your syllogisms are once again bass-ackwards.
[color=blue][color=green][color=darkred]
>> >> [...] If you take too much pain in porting the code,
>> >> somewhere along the line the cost of a complete rewrite
>> >> proves to be lower and the code is "not portable". (You
>> >> sometimes find that out too late.)
>> >
>> > Now tell me who's being black and white?[/color]
>>
>> If the cost is $17,000, that's a "degree".[/color]
>
> No, that's a *MEASURE*. Measures, like cost, can go to infinity (in
> theory). Degrees, as it is meant here, basically is between 0% and
> 100% (between 0 and 360 if you are talking about a circle, but its the
> same idea). Do you see the difference?[/color]

Now that you say "as is meant here" I see the difference *to you*.
But I'm not privy to what's inside your head. (That separation
thing again.) I tried your first dictionary link and found
your preferred definition seventh on the list. Several of the
earlier ones were consistent with my usage. Nyah.
[color=blue][color=green]
>> If the question is
>> "Is cost less than $17,000?" that's a Boolean. Black and white.[/color]
>
> Ok, but you miss my point. Why is it ok for *you* to synthesize an
> arbitrary black and white, but when I just cite a commonly accepted
> black and white (source code being portable or not), you get to deride
> me for it?[/color]

Sigh. What I said was that you make a Boolean out of a quantity
by using it in a comparison predicate. I used that as an
example of how people can conclude that a program is "not
portable" by performing some sort of implicit or explicit
quantitative estimate. The point is that portability
becomes a Boolean *only* when you apply a predicate to it.
[color=blue][color=green][color=darkred]
>> > Each of those languages was *painstakingly ported*. As posted by
>> > Walter Robinson in this thread, apparently the Perl source code (which
>> > is in C) is a horrendous mess to port to each platform.[/color]
>>
>> Shows what happens when you believe more in Perl than in C, I'd say.[/color]
>
> But the problems, in the case, *came* from C, the language it was
> implemented in. Once its up and running, presumably, he'll have the
> portable Perl language ready for him to use.[/color]

Other people have challenged your presumption better than I can.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com