What about namespaces ?

[Joe keane]

As long as we're talking about lousy linkers, C89 also allowed the
linker to ignore differences in case, so possibly there would be no
point in using both cases in your macro expansions.

worst case

Allowed characters are space, uppercase letters, digits, '.', '$'.
Space is used in a predefined way for symbols less than six characters;
the punctuation is for assembly programmers who know what they are doing
and would like to stay out of the way of those darn C programmers.

about two billion codes

 

[lawrence.jones]

And this is -totally- unworkable. I mean really, 'window_draw' and
'window_destroy' are the same?

Which is why you don't call them that, you call them wndraw and wndest.
I know it's hard to believe, but people actually managed to write
complex software systems under those kinds of restrictions for decades.

Realistically, if one were confined to such a linker, it would be
necessary to implement some sort of symbol hashing, to write at-all
non-trivial software, and avoid insane programmers.

Some implementations on such platforms did choose to go with a
proprietary object file format and linker, but that makes
interoperability with other languages problematic. (Yes, people used to
actually use different languages for differents pieces of a single
program.)

 

[Nomen Nescio]

Which is why you don't call them that, you call them wndraw and wndest.
I know it's hard to believe, but people actually managed to write
complex software systems under those kinds of restrictions for decades.

That's true but we had mostly 8 characters for labels and 7 for external
names. I don't know if I could have survived with only 6 ;-)

Are there any other kind?

Some implementations on such platforms did choose to go with a
proprietary object file format and linker, but that makes
interoperability with other languages problematic. (Yes, people used to
actually use different languages for differents pieces of a single
program.)

They still do, only they tend to interoperate much better on almost all
platforms than they did before.

 

[Joe keane]

As long as we're talking about lousy linkers, C89 also allowed the
linker to ignore differences in case, so possibly there would be no
point in using both cases in your macro expansions.

worst case

Allowed characters are space, uppercase letters, digits, '.', '$'.
Space is used in a predefined way for symbols less than six characters;
the punctuation is for assembly programmers who know what they are doing
and would like to stay out of the way of those darn C programmers.

about two billion codes

 

[Keith Thompson]

worst case

Allowed characters are space, uppercase letters, digits, '.', '$'.
Space is used in a predefined way for symbols less than six characters;
the punctuation is for assembly programmers who know what they are doing
and would like to stay out of the way of those darn C programmers.

about two billion codes

You say that linker symbols can contain space, '.', and '$'? Do you
have some specific linker in mind?

 

[BartC]

You say that linker symbols can contain space, '.', and '$'? Do you
have some specific linker in mind?

I think he means the implied spaces, after a name shorter than 6 characters
(although that only makes sense if all names are padded out to the same
length).

And my Nasm assembler doesn't seem to mind "." and "$" inside global names,
so I'd guess the linker will accept it too.

 

[Keith Thompson]

I think he means the implied spaces, after a name shorter than 6 characters
(although that only makes sense if all names are padded out to the same
length).

And my Nasm assembler doesn't seem to mind "." and "$" inside global names,
so I'd guess the linker will accept it too.

My point is that nothing in the C standard suggests that space, '.', and
'$' are valid characters. C89/C90 merely says that external names have
at least 6 significant initial characters, possibly case-insensitive.

A linker that's part of a conforming C89 implementation needn't accept
anything other than letters, digits, and underscores.

 

[Joe keane]

Perhaps writing a proper linker is an option. How difficult can it be?

Sometimes it's easier to just fix the problem.

 

[Joe keane]

Do you have some specific linker in mind?

I stole this from RSTS filenames.

From the PDP-10, it looks obvious where the magic number six comes from.
So it has 6-bit bytes. From there you can see why lower case is usually
not allowed in filenames et cetera.

On the PDP-11, you'd be crazy to have other than eight-bit bytes. So
then everyone agrees on ASCII and disagrees on what if the last bit is
set. But you can still do funny stuff.

 

[Martin Ambuhl]

Joe keane wrote on Sunday, April 15, 2012 12:46 PM (comp.lang.c):

I stole this from RSTS filenames.

From the PDP-10, it looks obvious where the magic number six comes from.
So it has 6-bit bytes. From there you can see why lower case is usually
not allowed in filenames et cetera.

The PDP-10 "byte" was any size from 1-36 bits using the bype-pointer
instructions. Symbol tables rarely used 6-bit characters, but an even
smaller character set using RAD50 (modulo decimal 40 = octal 50).
It was not unusual to use 5 7-bit bytes or 4 9-bit bytes in a 36 bit word.
And you could easily have 4 8-bit bytes with 4 bits to to play with as flags
or error checking.

 

[BartC]

Joe keane wrote on Sunday, April 15, 2012 12:46 PM (comp.lang.c):


The PDP-10 "byte" was any size from 1-36 bits using the bype-pointer
instructions. Symbol tables rarely used 6-bit characters, but an even
smaller character set using RAD50 (modulo decimal 40 = octal 50).

Radix-50 was designed to store 3 characters in 16-bits, or 6 characters in
32-bits.

But the pdp-10 had 36-bits and could also use 'Sixbit' encoding to more
easily store six 6-bit characters in a machine word. You got a 6-bit
character subtracting 32 from the Ascii code. That's easier than mapping to
a totally new character set and using multiplication to pack every 3 chars
into 16-bits.

I can't remember whether the actual file system and linker programs, which
were usually restricted to 6 characters, used radix-50 or sixbit, but the
latter would seem to be the sensible choice on that machine (radix-50 seemed
more a pdp-11 thing). (Certainly I for one used sixbit for symbol tables,
and never radix-50.)

 

[Tim Rentsch]

To be convincing, any proposal to add a significant language
feature to C needs to make a compelling argument that the
benefits of doing so substantially outweigh the costs.

I think it's hard to make such an argument compelling for
namespaces, since (1) having namespaces doesn't add much
expressive power, and (2) obviously namespaces are not a
prerequisite for building (large) programs, given the
existence of multi-million-line C programs that do okay
without namespaces.

It's also quite possible to write multi-million-line C programs using
i = i + 1 instead of i++, but yet the increment operator still is a valuable
C feature. [snip elaboration]

Just a few observations:

The expression 'i = i+1' is not equivalent to 'i++'.

The '++' operators adds only a small amount of expressive
power to C, but it is still more than namespaces add.

The effect of having '++' in the language is a fairly
small delta to the rest of the language specification.
The effect of namespaces would be enormous in comparison.

Comparing the two benefit/cost ratios, it's easy to see
why having having namespaces could be a bad idea even if
having ++ is a good idea.

 

[David Thompson]

(e-mail address removed) (Joe keane) writes:

[snip: C89 allows external names limited to 6chars case-insensitive]

You say that linker symbols can contain space, '.', and '$'? Do you
have some specific linker in mind?

Probably any of the DEC ones for PDP-11 (RT-11, RSX, RSTS).

http://en.wikipedia.org/wiki/DEC_Radix-50