obfuscated

[Peter Nilsson]

Re: obfuscated

Clark S. Cox III wrote:

dcorbit@connx.c om wrote:

Within a C source file, isn't ISO 646 character set assumed?

>
No.

Even if it where, characters in constants and literals get mapped to
the execution character set anyway.

--
Peter

[jmcgill]

Re: obfuscated

dcorbit@connx.c om wrote:

It is possible for argc to be zero and argv[1] to be a null pointer.

Because you cannot necessarily rely on main(int, char**) being called
the way you expect? Or something else? I have never considered this
before. But obviously there's nothing very special about main.
Anything that can get the appropriate linkage can call it with whatever
stack it wants, right?

[Richard Heathfield]

Re: obfuscated

Pedro Graca said:

dcorbit@connx.c om wrote:

>Of course, argc can be zero. There is no requirement in the C language
>that argc is at least one and that argv[0] contains the program name.
>It is possible for argc to be zero and argv[1] to be a null pointer.

----------------------------------------------^
>
Do you mean
it is possible for argc to be zero and argv[0] to be a null pointer/

Yes, that's what he means. argv[argc] is NULL by definition.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Re: obfuscated

jmcgill said:

Mark McIntyre wrote:
>

>No, this isn't required by the Standard, and indeed realworld
>implementation s will break this assumption (think non-english
>character sets, or EBCDIC or whatever)

>
I was thinking of those, and I was under the impression that lexical
ordering was guaranteed, but I guess not.

EBCDIC's okay with the ordering, but the alphabets are non-contiguous,
coming as they do in rows of ten on boundaries of sixteen.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[Mark McIntyre]

Re: obfuscated

On Tue, 10 Oct 2006 14:51:32 -0700, in comp.lang.c , jmcgill
<jmcgill@email. arizona.eduwrot e:

>Mark McIntyre wrote:
>

>No, this isn't required by the Standard, and indeed realworld
>implementation s will break this assumption (think non-english
>character sets, or EBCDIC or whatever)

>
>I was thinking of those, and I was under the impression that lexical
>ordering was guaranteed, but I guess not.

Probably doesn't work too well in any character set pertaining to
cyrillic, greek, chinese, arabic, hebrew, turkish, etc etc.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

Re: obfuscated

On Tue, 10 Oct 2006 20:19:14 -0700, in comp.lang.c , jmcgill
<jmcgill@email. arizona.eduwrot e:

>dcorbit@connx. com wrote:
>

>It is possible for argc to be zero and argv[1] to be a null pointer.

the zeroth argument of main() is reserved for the program name, but an
implementation is not obligated to populate it. In an embedded
environment, there would be no need to.

Plus you can call main recursively in C.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Simon Biber]

Re: obfuscated

Mark McIntyre wrote:

On Tue, 10 Oct 2006 14:51:32 -0700, in comp.lang.c , jmcgill
<jmcgill@email. arizona.eduwrot e:
>

>Mark McIntyre wrote:
>>

>>No, this isn't required by the Standard, and indeed realworld
>>implementatio ns will break this assumption (think non-english
>>character sets, or EBCDIC or whatever)

>I was thinking of those, and I was under the impression that lexical
>ordering was guaranteed, but I guess not.

>
Probably doesn't work too well in any character set pertaining to
cyrillic, greek, chinese, arabic, hebrew, turkish, etc etc.

All of those character sets still have lexical ordering of Latin letters
A to Z. They are almost always built on ASCII as a base and use the
characters with high bit set to encode all the other required characters
(sometimes in pairs or quads). This is the case with ISO-8859 series,
ISO-2022 series, EUC series, Shift-JIS, GB2312, GB18030, Big5,
Big5-HKSCS, etc.

As for lexical ordering of other alphabets in their own charsets, that
varies. Some languages don't even have a well-defined ordering. There
are several possible sort orders for Chinese characters (based on
radicals, pronunciation or number of strokes).

--
Simon.

[Mark McIntyre]

Re: obfuscated

On Thu, 12 Oct 2006 05:58:39 +1000, in comp.lang.c , Simon Biber
<news@ralmin.cc wrote:

>Mark McIntyre wrote:

>On Tue, 10 Oct 2006 14:51:32 -0700, in comp.lang.c , jmcgill
><jmcgill@email .arizona.eduwro te:
>>

>>Mark McIntyre wrote:
>>>
>>>No, this isn't required by the Standard, and indeed realworld
>>>implementati ons will break this assumption (think non-english
>>>character sets, or EBCDIC or whatever)
>>I was thinking of those, and I was under the impression that lexical
>>ordering was guaranteed, but I guess not.

>>
>Probably doesn't work too well in any character set pertaining to
>cyrillic, greek, chinese, arabic, hebrew, turkish, etc etc.

>
>All of those character sets still have lexical ordering of Latin letters
>A to Z

Chinese doesn't have any latin letters, its all pictures. Greek goes
abgde etc. Arabic doesn't use ASCII letters. etc.

>. They are almost always built on ASCII as a base

I fear you're thinking of national extensions to ISO-646.

>As for lexical ordering of other alphabets in their own charsets, that
>varies. Some languages don't even have a well-defined ordering.

Absolutely.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Simon Biber]

Re: obfuscated

Mark McIntyre wrote:

On Thu, 12 Oct 2006 05:58:39 +1000, in comp.lang.c , Simon Biber
<news@ralmin.cc wrote:
>

>Mark McIntyre wrote:

>>Probably doesn't work too well in any character set pertaining to
>>cyrillic, greek, chinese, arabic, hebrew, turkish, etc etc.

>All of those character sets still have lexical ordering of Latin letters
>A to Z

>
Chinese doesn't have any latin letters, its all pictures. Greek goes
abgde etc. Arabic doesn't use ASCII letters. etc.

I was referring to lexical ordering of Latin letters, not of other
characters. Chinese character sets DO have the full set of Latin
letters, alongside all the Chinese characters. So do Arabic character
sets. I am yet to see one that does not provide all the Latin letters
alongside the Arabic ones. And the Latin letters are in lexical order A
- Z. I said nothing about the ordering of the Arabic letters or Chinese
characters.

>. They are almost always built on ASCII as a base

>
I fear you're thinking of national extensions to ISO-646.

No, I'm referring to the specific character sets I mentioned.

--
Simon.

[Dave Thompson]

Re: obfuscated

On Wed, 11 Oct 2006 06:14:35 +0000, Richard Heathfield
<invalid@invali d.invalidwrote:

jmcgill said:
>

Mark McIntyre wrote:

No, this isn't required by the Standard, and indeed realworld
implementations will break this assumption (think non-english
character sets, or EBCDIC or whatever)

I was thinking of those, and I was under the impression that lexical
ordering was guaranteed, but I guess not.

>
EBCDIC's okay with the ordering, but the alphabets are non-contiguous,
coming as they do in rows of ten on boundaries of sixteen.

s/ten/nine and eight (averaging 8.6overbar)/

But you do rhyme with 'seas of green', FWIW.


- David.Thompson1 at worldnet.att.ne t

[Dave Thompson]

Re: obfuscated

On 10 Oct 2006 11:54:37 -0700, "Ancient_Hacker " <grg2@comcast.n et>
wrote:

>
Frederick Gotham wrote:
>

The code is non-portable as it makes the unfounded presumption that:

'J' == 'I'+1

>
>
Ah yes, any computers out there using the 5-bit Baudot code are going
to print complete gibberish.
>

Not to mention that 'Baudot' (officially IA2, the International
(Teletype) Alphabet #2): does not have lowercase letters and several
punctuation or 'special' characters that are required in the basic
(minimum) execution character set; has codes for the digits that are
not consecutive as required, as well as being shift-state dependent
which may not be specifically prohibited but doesn't make sense for
the ctype.h functions.

Seriously, in IBM EBCDIC, the letters are not contiguous, due to it
being derived from BCD card codes, which as everybody knows, had nine
rows, so the letters are in groups of nine, with seven codes in between
to pad to the next multiple of 16.
>

Cards had nine digit rows plus three zone rows, twelve total; usually
only 0 and 1-9 were printed. "Bury me face down, 9 edge first."

- David.Thompson1 at worldnet.att.ne t

[Richard Heathfield]

Re: obfuscated

Dave Thompson said:

On Wed, 11 Oct 2006 06:14:35 +0000, Richard Heathfield
<invalid@invali d.invalidwrote:
>

>EBCDIC's okay with the ordering, but the alphabets are non-contiguous,
>coming as they do in rows of ten on boundaries of sixteen.

>
s/ten/nine and eight (averaging 8.6overbar)/

Yes, I was relying on my (obviously faulty) memory. Later, I had occasion to
look the table up, and noted that the alphabet was in nines rather than
tens, but by then I didn't recall having claimed otherwise. :-)

But you do rhyme with 'seas of green', FWIW.

Cue the solo on something brassy (tuba?).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at above domain (but drop the www, obviously)

[lawrence.jones@ugs.com]

Re: obfuscated

Dave Thompson <david.thompson 1@worldnet.att. netwrote:

>
Cards had nine digit rows plus three zone rows, twelve total; usually

Ten digit rows -- 0 can be either a zone or a digit, depending on the
particular usage.

-Larry Jones

I won't eat any cereal that doesn't turn the milk purple. -- Calvin