Re: <ctype.h> toLower()

From: Ian Woods (newspub2_at_wuggyNOCAPS.org)
Date: 11/25/03 

Date: Tue, 25 Nov 2003 16:31:54 +0000 (UTC)

<preamble>These posts are getting really long... time for some snippage!
</preamble>

"ellie fant" <pcrcutitout1000011@uko2.co.uk> wrote in
news:1069733157.246334@news.minx.net.uk:
> "Josh Sebastian" <curien@cox.net> wrote in message
> news:pan.2003.11.25.02.35.03.111931@cox.net...
>> On Tue, 25 Nov 2003 01:36:15 +0000, ellie fant wrote:
>> > "Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> wrote in message
>> > news:Pine.LNX.4.58-035.0311241905220.17029@unix46.andrew.cmu.edu...
>> >
>> > You said above that this was an ANSI C
>> > compliant compiler and now your saying it's not. Make up your mind.
>>
>> No, he said that the documentation /claimed/ it was ANSI compliant.
>> Apparently, they fail to meet their claim in at least one respect.
>> This wouldn't be the first time a product didn't live up to its
>> advertising.
>
> But the above quote from the standards covered this did it not?
> This compiler is a free standing compiler and therefore allowed to
> include it's own implementation of libraries?

If it's a free standing implimentation, then the scope of the standard is
restricted. In particular, the programs entry point is implimentation
defined and only limitted parts of the standard library are required to
be included.

5 A strictly conforming program shall use only those features of the
language and library specified in this International Standard. It shall
not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit.

4 The two forms of conforming implementation are hosted and freestanding.
A conforming hosted implementation shall accept any strictly conforming
program. A conforming freestanding implementation shall accept any
strictly conforming program that does not use complex types and in which
the use of the features specified in the library clause (clause 7) is
confined to the contents of the standard headers <float.h>, <iso646.h>,
<limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A
conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program.3)

(* This is all from C99, since I don't have a copy of C89)

>> > This compiler is stating that it's implementation of tolower is
>> > designed for ASCII platforms, if you remove the word ASCII the
>> > meaning changes. The effects of the ASCII function is to convert
>> > uppercase to lower case ASCII characters, the Abrev ASCII is
>> > important because it makes it clear that this function is intended
>> > for nothing other than ASCII platforms.
>>
>> Not really. It is an implementation detail. By analogy, one wouldn't
>> say that operator+ for ints does entirely different things on
>> big-endian versus little-endian machines. Either way, it adds the two
>> ints together. That it happens to use a different algorithm to do so
>> is irrelevant.
>
> But of course it makes a difference if the implementation only covers
> ASCII machines. The programmer should know about this and when
> considering portability if makes a heck of a big difference..

The reason why they're telling you is because in an embedded environment
you can usually choose your execution character set. If, for example, I
have an LCD hanging off my device it might not be ASCII. The people who
wrote the library explicitely mention that they're using ASCII as the
execution character set in their functions so that you know that they
are... and that if you need something else (like, the character set the
LCD understands) then their library functions won't do it.

A hosted implimentation on the other hand usually has it's execution
character set enforced by the operating system upon which it's running,
which may or may not be ASCII... and yet, properly written code will work
perfectly fine on two systems with different execution character sets.

>> > Who cares if the interface is portable it's the implementation that
>> > matters. You could say the interface int foo() is completely
>> > portable but that means nada.
>> > The implementation can change on different platforms , so you
>> > *cannot* assume the interface will be suitable for the target
>> > platform.
>>
>> Umm... the implementation changes to ensure that the pre- and
>> post-conditions are met on various platforms.
>
> lol what does this mean?
 
>>
>> >> #include <stdio.h>
>> >> #include <ctype.h>
>> >> int main()
>> >> { putchar(tolower('A')); putchar('\n'); return 0; }
>> >>
>> >> *must* output the letter 'a', followed by a newline, on every
>> >> single platform in existence. That's what everyone here means
>> >> when we say a construct is "portable" -- that you can use it
>> >> everywhere with the same effects.
>> >
>> > That's nonsense that code will *not* work on every single platform
>> > in existence.
>>
>> Name one where it won't.
>
> Err I think you are talking about using the identifier across C
> compilers. I am talking about the compiled object code when I mean
> portable.

Your idea of portable is somewhat flawed. Object code is, by definition,
not portable. Source code on the other hand may or may not be portable,
or even portable to different degrees. When people write C programs, (C
being a language is defined by standards documents) they should fit the
language standard perfectly... unless there's a very good reason why they
don't.

>>
>> > Firstly the implementation of that code is totally dependant on the
>> > platform on which it is compiled.
>>
>> So?
>
> So this is wrong , the code you write is not only supposed to work on
> the same type of machine that you compile it on.

Err, the code you write will work on /any/ machine you compile it for (if
you compile it with a hosted implimentation for that platform).

#include <stdio.h>

int main(void) {
  puts("I work!");
  return 0;
}

I can compile that on my windows box, using a C compiler for windows and
run the executable on a wide range of windows boxen. I also compiled it
on my linux box, and that executable and it'll run on a wide of linux
boxen. If I compile it for the DeathStation 9000, I'm sure it'll work on
there too.

Note that it's the source code which is portable, not the compiled object
code.

>> > Secondly every platform in existence does not have an output
>> > device.
>>
>> Name one hosted environment that doesn't. (Remember: tape reals,
>> magnetic drums, teletypes, files, network interfaces, LCD displays,
>> etc count as "output devices".)
>
> A PIC microcontroller.
> Who said 'hosted environment' we're talking about target platforms.

C source code written for the PICs freestanding implimentation will not
(in general) be portable to any other implimentation (freestanding or
hosted) for the simple reason that the C standard doesn't require that
the platforms provide the same libraries or even the same program entry
point.

>> > And it's not portable because if I want to compile a library and I
>> > use that tolower function the library will only work on machines
>> > similar to the one on which it is compiled. This means you cannot
>> > use this function when creating portable libraries.
>>
>> As I informed you elsethread, "portability" doesn't apply to object
>> code, so your point is moot.
>
> Well your wrong on that because this is exaclty what portable means.

Here's my library. It's only got one function, and it doesn't do much,
but it is portable... at least to all hosted implimentations.

/* foo.h */

int makelower(int c);

/* foo.c */

#include <ctype.h>

int makelower(int c) {
  return tolower(c);
}

I can compile that, and turn it into a library on any hosted
implimentation I like secure in the knowledge it'll do what I expect.

The code is most definitately portable.

There's not much point talking about code being portable between
freestanding implimentations for the reasons I've previously put.

Ian Woods

Relevant Pages

  • Re: learning asm.
    ... No need to apologise...I'm so all over the place myself with posts ... problem...such libraries are monsterous and lead to _more complex_ ... "portability" actually isn't needed or a desirable attribute then this ... loader-time to make, I suppose, a "custom jump table" for that program ...
    (alt.lang.asm)
  • Re: <ctype.h> toLower()
    ... I think you are confusing portability with binary compatibility. ... to be CPU specific. ... compiler and thencan specify the machine type. ... >> Object libraries are definately platform specific. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: <ctype.h> toLower()
    ... > If it's a free standing implimentation, then the scope of the standard is ... I am talking about the compiled object code when I mean ... advantages of object code far outweigh source code in terms of portability. ... > you compile it with a hosted implimentation for that platform). ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Carrying Libraries on Your Back...
    ... > Why not build on an installed based of assemblies, ... > than porting libraries around, ... download source code ... compile local source against header files ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Using Lattice ispLEVER with VHDL libraries
    ... I am assuming there are some advantages to using the IDE rather than ... I also can't see to get Modelsim to work with ispLever, ... You will have to read about the tool you use to specify compile ... user defined libraries to get things to go under ispLever. ...
    (comp.arch.fpga)
Loading