«

pete <> writes:
> Jordan Abel wrote:
>> >> Your reading would forbid third-party POSIX-compliance add-ons.
>> >
>> > Maybe.
>> > POSIX isn't ANSI C, is it?
>> > Didn't POSIX.1c redefine errno as a service?
>>
>> eh?
>>
>> posix doesn't define anything that conflicts with ansi c
>> - what are you on about?
>
> POSIX.1c redefines errno as a service that
> can access the per-thread error
> number as follows (ISO/IEC 9945:1-1996, §2.4):

C99 says that errno

expands to a modifiable lvalue that has type int, the value of
which is set to a positive error number by several library
functions. It is unspecified whether errno is a macro or an
identifier declared with external linkage.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Jordan Abel <> writes:
[...]
> It's bad form to followup to yourself.

Um, why? I've done it myself a number of times when I've thought of
something after I've posted a message.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

On 2005-11-14, Keith Thompson <kst-> wrote:
> Jordan Abel <> writes:
> [...]
>> It's bad form to followup to yourself.
>
> Um, why? I've done it myself a number of times when I've thought of
> something after I've posted a message.

I guess my statement was based on a somewhat naive belief that supercede
would actually be likely to work - sorry

Jordan Abel wrote:
>
> On 2005-11-14, pete <> wrote:
> > Jordan Abel wrote:
> >
> >> >> Your reading would forbid third-party POSIX-compliance add-ons.

I have nothing left from the C standard to show.
I don't really know enough about posix to discuss it.

--
pete

pete wrote:

> William Krick wrote:
>
>> Actually, when you cleaned up the return conditions, you left out some
>> of the conditions and broke the code. I've added them back in but I'm
>> sure it could still be simplified...
>>
>> int str_ccmp( const char *s1, const char *s2 ){
>> int c1, c2;
>>
>> for( ; ; s1++, s2++ ){
>> c1 = tolower( (unsigned char) *s1 );
>> c2 = tolower( (unsigned char) *s2 );
>>
>> if (c1 != c2 || c1 == 0) {
>> if( c1 > c2 ) return 1;
>> if( c1 < c2 ) return -1;
>> if( c1 == 0 ) return 0;
>> }
>> }
>> }
>
> int str_ccmp( const char *s1, const char *s2 )
> {
> int c1, c2;
>
> do {
> c1 = tolower( (unsigned char) *s1++ );
> c2 = tolower( (unsigned char) *s2++ );
> } while (c1 == c2 && c1 != 0);
> return c2 > c1 ? -1 : c1 > c2;
> }
>

I still find the version I posted earlier to be clearer:


int strcasecmp( const char *s1, const char *s2 )
{
while (1)
{
int c1 = tolower( (unsigned char) *s1++ );
int c2 = tolower( (unsigned char) *s2++ );
if (c1 == 0 || c1 != c2) return c1 - c2;
}
}

mostly because the signt of an uninitialised variable makes my
guts ache (and because I see no merit, absent some /specific/
documentation, for working so hard on the return value).

If the scope rules for do/while were more useful, I'd use it;
but they aren't.

--
Chris "another virtual machine" Dollin
time is just space under pressure. squeeze!

Chris Dollin wrote:

> I still find the version I posted earlier to be clearer:

We all think like that.

--
pete

pete wrote:

> Chris Dollin wrote:
>
>> I still find the version I posted earlier to be clearer:
>
> We all think like that.

That's not the impression I'm getting. By the way, I /did/
supply some reasons /why/; you're not /required/ to comment
on them, of course.

--
Chris "optionality is not prohibition" Dollin
time is just space under pressure. squeeze!

On Mon, 14 Nov 2005 00:53:28 +0000 (UTC), in comp.lang.c , Jordan Abel
<> wrote:

>On 2005-11-14, pete <> wrote:
>> pete wrote:
>>>
>>> 7.26 Future library directions
>>>
>>> 1 The following names are grouped under individual headers for
>>> convenience. All external names described below are reserved no
>>> matter what headers are included by the program.
>>>
>>> 7.26.11 String handling <string.h>
>>> 1 Function names that begin with str, mem, or wcs and a lowercase
>>> letter may be added to the declarations in the <string.h> header.
>>
>
>It's bad form to followup to yourself. And stop citing C99 at me, that's
>not the standard in effect in 99% of implementations.

Irrelevant, since C89 had essentially identical wording.

>I still see
>"function names" [which refutes your 'could be using it for other
>purposes' claim] and '_may_ be added' [which tells me that if they're
>NOT added, they're ok to use].

Not at all - how can you tell they're not there?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

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

On 2005-11-14, Mark McIntyre <> wrote:
> On Mon, 14 Nov 2005 00:53:28 +0000 (UTC), in comp.lang.c , Jordan Abel
> <> wrote:
>
>>On 2005-11-14, pete <> wrote:
>>> pete wrote:
>>>>
>>>> 7.26 Future library directions
>>>>
>>>> 1 The following names are grouped under individual headers for
>>>> convenience. All external names described below are reserved no
>>>> matter what headers are included by the program.
>>>>
>>>> 7.26.11 String handling <string.h>
>>>> 1 Function names that begin with str, mem, or wcs and a lowercase
>>>> letter may be added to the declarations in the <string.h> header.
>>>
>>
>>It's bad form to followup to yourself. And stop citing C99 at me, that's
>>not the standard in effect in 99% of implementations.
>
> Irrelevant, since C89 had essentially identical wording.
>
>>I still see
>>"function names" [which refutes your 'could be using it for other
>>purposes' claim] and '_may_ be added' [which tells me that if they're
>>NOT added, they're ok to use].
>
> Not at all - how can you tell they're not there?

The specific mechanism isn't particularly relevant, but in many cases if
a function is not provided by the implementation, or is not declared in
the header, it is possible [either always, or with implementation-specific
options] for the program to fail to translate.

In article <>, Jordan Abel <> writes:
> On 2005-11-13, Michael Wojcik <> wrote:
> > In article <>, Jordan Abel <> writes:
> >> On 2005-11-11, Michael Wojcik <> wrote:
> >
> >> > For a function like your "strcasecmp" (note that this name is
> >> > reserved to the implementation, and you should not use it)
> >>
> >> which is why it's #ifndef'd to only compile on systems that don't
> >> provide it.
> >
> > So what? That identifier is still reserved to the implementation.
>
> As function names in stdlib.h and string.h - they are not reserved for
> any other purpose, and if it has been determined that the headers in
> question don't contain that function name...

Wrong. C90 7.13: "All external names described below are reserved
no matter what headers are included by the program"; 7.13.8: "Function
names beginning with str, ...".

> > Perhaps the next revision of the implementation for that platform
> > *will* include it.
>
> At which point HAVE_STRCASECMP will presumably test true,

Now there's a compelling argument. "This is wrong, but presumably
it'll go away if it might cause a problem." Why not avoid the
problem in the first place?

> since these
> are generated by seeing if a test program trying to use it successfully
> translates.

And you know that how?

> > Perhaps that implementation uses it for some other purpose - it's not
> > required to document that.
>
> It's not allowed to do that. The language of the standard only permits
> implementations to use it as a function name, and only in stdlib.h or
> string.h. Nowhere else and for no other purpose.

Wrong. The identifier is reserved to the implementation. The
implementation *may* add it to string.h, but need not.

If the implementation does add it to string.h, it need not do what
the OP's function does.

--
Michael Wojcik

Recently, they appeared at the reopening of the Brookdale Library,
luring passersby with the opportunity to be anonymously silly.