Re: <ctype.h> toLower()

From: Richard Heathfield (dontmail_at_address.co.uk.invalid)
Date: 11/22/03 

Date: Sat, 22 Nov 2003 11:25:27 +0000 (UTC)

ellie fant wrote:

>
> "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
> news:bpn0re$h3f$1@titan.btinternet.com...
>> ellie fant wrote:
>>
>> > "Richard Heathfield" <dontmail@address.co.uk.invalid> wrote in message
>> > news:bpm1rn$pug$1@sparta.btinternet.com...
>> >> >
>> >> > Doesn't the array exist then?
>> >>
>> >> Yes, of course, but not in that translation unit.
>> > Do you also need to link in an external TU then?
>>
>> No. I need to link in the standard C library. Please read
>> about translation units, and find out what they actually
>> are, before using the term again.
>> Thanks.
>
> You need to link to the standard library do you ?

Yes.

> I don't need to do that.

Yes, you do, if you want your programs to use anything at all from the
standard library.

> So what is the output from your compiler if it's not a TU,

The output of a compiler is generally called an object file. The translation
unit is the input, not the output.

> and why do you
> think the 384 element array does not exist in this TU?

It's in the standard library, the relevant parts of which will be linked to
my program at the appropriate time.

>> > So your admitting the output of the implementation you posted is not
>> > suitable for all environments.
>>
>> I have never claimed that it /is/ suitable for all environments.
>> The point is that the implementation has a better idea of what
>> is suitable for its given environment than I, a writer of
>> portable source code, am likely to be able to manage. I am much
>> more likely to get decent code on all environments by relying
>> on the implementation's decisions about its environment than
>> by making those decisions myself within my source!
>
> But you said it was portable, surely portable means it can be ported to
> all other environments.

Yes; a call to tolower() is a call to tolower(), irrespective of how
tolower() is implemented. That's the point.

> If you rely on your implementations decision, then you have you lost the
> ability to think for yourself?

No, I have gained the ability to convert to lower case correctly on any
platform, without even having to know which character set is used on that
platform.

> Why don't you decide what is best implementation after all you know what
> the target platform is , your compiler doesn't.

You have that precisely the wrong way around. My compiler knows what its
target platform is. I don't necessarily know on which platforms my code
will be used. In fact, several people have told me that they have
(successfully) used my code on platforms I didn't even know existed.

>> > Do you use a different compiler to get a different implementation of
>> > the tolower function?
>>
>> No. I use a different compiler (or rather, a different implementation) if
> I
>> need to target a different environment. How that implementation
>> implements tolower on that environment is that implementation's business.
>
> So is this what you suggest to get the implementation you need? Use a
> different compiler?

I don't /care/ about the implementation. As long as it's a conforming
implementation, that's all that matters.

> But I just paid £400 for this one, why do I need a different compiler when
> I am happy with this one.

You don't, obviously, any more than I need to buy a mainframe computer and
mainframe compiler in order to write C code that works on a mainframe
computer.

> I think the code this compiler makes is ok, it's
> only you and a handfull other half wits who thinks its wrong.

Provided it is used correctly, it's fine for ***your platform***. You can't
rely on its working on ***other*** platforms.

>> > I am talking about portability of compiled programs across different
>> > platforms.
>>
>> Here are three different platforms: Windows, VM/CMS, AmigaDOS.
>>
>> Do you have even one single compiled program that will run on all three
>> of those native platforms, without any emulators running? Do you, in
>> short, have the faintest idea of what you're talking about?
>
> I've already pointed this out to you. What do you think I meant when I
> said over 99% of all working code is not portable, I told you this before
> and you wouldn't believe me.

Non-portable code is sometimes necessary, but always undesirable if a
satisfactory portable equivalent can be found. Probably in the region of
90% (for some random but high value of 90) of the C code I write is
portable to any hosted implementation, and a good deal of freestanding
implementations too. The inability or unwillingness of other people to
write portable code does not imply that writing portable code is a bad
thing to attempt.

>> > You seem to mean shifting source code from one compiler to another.
>> > :-s
>>
>> That's *precisely* what I mean. I expect my code to compile and work
>> correctly under gcc, C/370 and LE/370, CodeWarrior, Visual C, lcc,
>> Borland C, HiSoft C, EiC, and any other conforming C compiler you care to
>> mention.
>
> But that's not what people mean when they talk about portable software.

Yes, it is.

> Portable software is software that will run on a Toshiba laptop and it
> will work on a AMD desktop system and it will work on a HP handheld and it
> will work on a nokia phone.

Right. And it will also run on a mainframe, and a Mac, and an Amiga, and an
Alpha, and a Cray.

> This is the meaning of portable software, not your idea of moving source
> code between compilers:-s

So are you telling me that, to write a portable C program, you write the
code in C, compile it in Visual Studio, and then transfer the resulting
executable binary image to the target machine? Is that really what you
believe?

> If that's what you really think portable software is your floating in
> space man.

<grin> You're kinda cute, you know that?

>> > You said you wouldn't touch microsofts macro with a barge pole
>> > so you are implying there is something wrong with it.
>>
>> There is. It's not portable. Their tolower() implementation, however,
>> conforms to the ISO C Standard, so I have no problem calling that. And if
>> their tolower() implementation calls that macro, well, that's up to them,
>> and I have no problem with that as long as it works.
> Here he goes again with his interpreteation of portable <sigh>
> Even if it is not portable it still doesn't mean it's wrong

As long as it's used correctly, it's fine for that platform. But not
necessarily for other platforms.

> as I keep
> telling you 99% of all working code is not portable.

Certainly the vast majority of working code I produce is portable, so I
think you're wrong here.

> So your reason for saying it is wrong is wrong. :-s

No, you just don't understand the reason.

>>
>> > Here is the code again?
>> > #define _tolower(_c) ( (_c)-'A'+'a' )
>> >
>> > Now are you saying there is something wrong with it or not?
>> > :-)
>>
>> Yes, there are three things wrong with it. Firstly, it begins
>> with a leading underscore so I'm suspicious of it immediately
>> (because it shows that we're
>> dealing with an implementation-specific feature).
> No leading underscores are legal, there's nothing wrong with that.

Yes, it is legal for the implementation to use identifiers beginning with
leading underscores. That's what I said. Duh.

>> Secondly, the code itself
>> is not portable.
> There is no requirement in the C standards for code to be portable(in the
> way you use it).

No, there isn't. There isn't any requirement in the C standard for you to
write working code, or even to write any code at all.

>> Thirdly, it doesn't handle non-upper-case characters correctly.
> But it's designed only to handle upper case characters, if you write a
> piece of code to handle whole numbers you can't say it's wrong because it
> doesn't handle fractions. So your third point is nonsense as well as the
> other two

Please stay focused. I was explaining why I wouldn't use the function. I see
no reason to use a _tolower() routine that can't handle non-upper-case
characters when I can use a tolower() routine that is guaranteed to handle
them properly.

> <snip>
> You just said it was incorrect on 3 points but then you go on to say .."
> but If they decide to implement it it's fine by me."

I gave you three reasons why I wouldn't call it. I am perfectly happy to
call VC's tolower() function, and what that does under the hood is entirely
up to Microsoft, as long as the effect is precisely what the Standard
requires.

> You want the best of both worlds don't you , you want to criticise it to
> death but you still have to say it's ok because everyone knows it's
> microsofts code and it's well tried and tested and that it's good legal
> standard compliant code.

I do indeed want the best of both worlds, and I can /have/ the best of both
worlds by calling tolower() instead of _tolower().

> But YOU think it's wrong on 3 points

Actually, I merely gave three reasons why I wouldn't call it myself. I have
no problem with an implementation of tolower() calling _tolower() if that's
what it thinks is the best way to provide the conversion, /provided/ the
tolower() implementation behaves according to spec. 

-- 
Richard Heathfield : binary@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Quantcast