Re: <ctype.h> toLower()

From: ellie fant (pcrcutitout1000011_at_uko2.co.uk)
Date: 11/25/03 

Date: Tue, 25 Nov 2003 22:08:00 -0000

"Ian Woods" <newspub2@wuggyNOCAPS.org> wrote in message
news:Xns943EA803F3E5Enewspubwuggyorg@217.32.252.50...
> <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..

Exactly.

>
> 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.

Yes exactly.
>
> 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.
>
If your talking about source code it will work but if your creating a
portable library it won't work because you do not want the host platform to
define the execution character set, this would be unportable.

> >> > 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.

I disagree with this. Object code is not 'by definition not portable' it is
actually more portable than source code.
1) You can use object code across different languages , and you cannot do
that with source code.
2) Yes object code is limited to linkers that use the object format but
there are utilities which can convert the format of object code.
3) Object code created on a specific platform is not tied to that platfom
i.e.
    Obj code built on a intel machine can be used to create an executable
image on numerous different machines such as: Alpha. Motorolla,
PIC , Palm or whatever. .
4) The only limitation of object code is the object code format as there are
no standards in place to govern this *yet* but it still seems that the
advantages of object code far outweigh source code in terms of portability.

The term portability in every context has limitations whether your talking
about freight ships or programming, if your talking about C source code then
the limitations is C compilers (on hosted implementations) likewise if your
talking about object code then it's limitations are linkers that support the
obj format. This doesn't make object code unportable by definition.

>
> >>
> >> > 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).

Exactly what I'm saying.
The code will only work on the target platform you design it for.

>
> #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.

Yes my point of portability is that you can compile it on a windows box and
then port the object file to any other box and use it without recompiling.
As long as the target box supports the particular obj format, which it will
if the code is designed for that target platform. This way it's more
portable than source code as it can be written in a completely different
language i.e: C, C++. ASM, Fortran and Java can link to object files, I
don't know but there may be more.

>
> Note that it's the source code which is portable, not the compiled object
> code.
Nah I disagree , I think that's the wrong end of the stick as I explained
above.
>
> >> > 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.

Exactly.
However code compiled to an object format that the freestanding
implementation supports will work fine and can be ported between any
implementation that supports the format otherwise an object file convertor
utility will be required..

>
> >> > 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);
> }

Yes this SOURCE CODE is portable to all hosted implementations but it's not
portable to all implementations so:
a) the source code aint really portable unless it is a requirement for all
freestanding implementations to include a tolower function, which I'm not
sure about.
b) you said it was a library so to create a library this code would be
compiled into a lib file and the resulting TU would be tailored to suit the
platform on which it was compiled and therefore the library is not portable
at all.

>
> 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.

Yes but the library is always going to be tailored to the platform on which
it has been compiled. Therefore the library itself is not portable.

>
> The code is most definitately portable.

As long as the source code is standard compliant then it is always going to
be portable to any standard compliant compiler. I don't see the point in
calling source code portable when we have a standard to ensure that source
code will be portable.
Why not just say it is standard compliant? This meaning it is guaranteed to
work on any compliant compiler.(Almost always true :-) )

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

There's not much point in talking about source code being portable at all.
Could say the same as you said about object code. Source code is by
definition not portable.

Relevant Pages

  • Re: How to write to a file including full directory in C under Unix?
    ... you should stick to the standard C functions. ... it does not *always* reduce your portability. ... the program with mkdir. ... the program *not* compile and tell me that something doesn't work, ...
    (comp.lang.c)
  • Re: How to write to a file including full directory in C under Unix?
    ... you should stick to the standard C functions. ... the C standard always reduces your portability. ... the program with mkdir. ... the program *not* compile and tell me that something doesn't work, ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... As I and others have tried to impart to you, object code is by definition ... Source code on the other hand may or may ... > terms of portability. ... I can write a program on my windows box, compile it, and run it. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: <ctype.h> toLower()
    ... Source code on the other hand may or may not be portable, ... Object code is not 'by definition not portable' it is ... The only portability topical here is C ... >> you compile it with a hosted implimentation for that platform). ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Why tthe header is not declared ?
    ... how does it harm portability? ... compile the code in different systems. ... take a great leap to some strict perspective of Standard C, ... Comeau C/C++ with Dinkumware's Libraries... ...
    (comp.lang.c)