Uninitialized externals and statics

John Hascall hascall at atanasoff.cs.iastate.edu
Wed Aug 30 00:45:08 AEST 1989


In article <10859> gwyn at brl.arpa (Doug Gwyn) writes:
}In some article I rant and rave:

}>      What kind of idiot would design a character code with '0'..'9'
}>      in any other fashion.  The same can be said for 'a'..'z' and
}>      'A'..'Z', but we know which idiots would do that.
 
}Well, you see, it is not the job of X3J11 to determine what is idiotic
}and what is not.  It is X3J11's job to specify a maximally useful
}programming language.  Gratuitously excluding certain classes of
}architecture would violate the Committee's charter.

   If a standard is so broad as to include everything is it still a
   standard?  Is it wise to try to include every possible aberrant
   behavior (you are only going to encourage them)?  Where do you stop?
   Should also require that C compilers recognize the keywords in
   other languages (say Spanish) so as not to "gratuitously exclude
   certain classes" of programmers?

   If you are not going to restrict the "local alphabet" *
   characters to a contiguous sequence of integer values it certainly
   makes the problem of writing a portable sorting routine difficult.
   (The only alternative I can come up with off the top of my head is
   to have something like the following in a standard header:)

       #define _COLL_SEQ "abcdefghijklmnopqrstuvwxyz"

   and even that has it problems.


}If you were to consider EBCDIC's 8-bit bytes as signed, then the codes
}for '0' .. '9' would appear in descending order.  

   And if you were to consider them as tiny little floating point numbers,
   then the codes for '0'..'9' would make no sense at all.  :-)

}>(pps. I think trigraphs were a misguided effort as well)
 
}I think that most of X3J11 might even privately agree with that ...
}The real problem with trigraphs is that they've been misconstrued
}as an attempt to solve the international character set issue for
}practical programming purposes.  The current party line is that
}they're of use primarily in code transport among varying systems,
}not for everyday programmer use.

   That's the point.  They should be an international data transport
   standard not a C programming language standard.

   What if some group decides on a "insert other langauge here"
   standard that wants to use quadgraphs of $*$c, for example
   for this file transfer purpose.


John "Someone has to ask these stupid questions" Hascall

*  I was privately chided for my ethnocentric use of 'a'..'z'



More information about the Comp.lang.c mailing list