I was looking at the 1983 C sources of PostScript (via
https://computerhistory.org/blog/postscript-a-digital-printing-press/).

It uses typedef like this:

typedef long int integer;
typedef unsigned integer Offset;

That is, being able to apply 'unsigned' to a typedef-ed name, rather
than any of 'char short int long'.

I guess this is not legal C now; I just wondered at what point it
stopped being legal, if it ever was (perhaps compilers were just more lax).

On Tuesday, December 13, 2022 at 10:45:34 AM UTC-3, Bart wrote:
> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
> typedef long int integer;
> typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more lax).

Interesting.

I have posted here a question in the past how to "merge" typedef definitions..
The separation of type specifier and declarator in C makes everything more complex.

things like:

typedef int A[2];
typedef A *B [1];

B is
int (* [1]) [2]

I think this is one of the biggest problem of C.. but this bothers more implementers.

On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
....
> I think this is one of the biggest problem of C.. but this bothers more implementers.

The data representation of C types are incredible complex.

Also types can have extra parentheses that are useless like:
int (((a)));

On 13/12/2022 14:46, Thiago Adams wrote:
> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
> ...
>> I think this is one of the biggest problem of C.. but this bothers more implementers.
>
> The data representation of C types are incredible complex.
>
> Also types can have extra parentheses that are useless like:
> int (((a)));

Most languages will allow (((a))) in expressions too; it is not unusual.

What's different with C is treating a type specification as though it
was an expression too, which can be confusing if you come across it
unexpectedly. So:

f(x);

looks like a function call, but could equally be declaring 'x' of type
'f', depending on what 'f' actually is.

Mixing up expression syntax and type syntax was deliberate, but also a
mistake.

Bart <bc@freeuk.com> writes:

> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
> typedef long int integer;
> typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more
> lax).

I doubt it has ever been legal. Even K&R1 has the wording that rules it
out. Pre-K&R1 C might have been more lax, but for most of the time
before K&R1 C did not even have unsigned!

I wonder what else this generous compiler permitted. Could one do

typedef double number;
typedef long number hi_prec_num;

for example? I doubt it.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>> typedef long int integer;
>> typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now; I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more
>> lax).
>
>I doubt it has ever been legal. Even K&R1 has the wording that rules it
>out. Pre-K&R1 C might have been more lax, but for most of the time
>before K&R1 C did not even have unsigned!

It probably worked because:

#define unsigned

preceeded it in the translation unit.

On 2022-12-13, Bart <bc@freeuk.com> wrote:
> On 13/12/2022 14:46, Thiago Adams wrote:
>> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
>> ...
>>> I think this is one of the biggest problem of C.. but this bothers more implementers.
>>
>> The data representation of C types are incredible complex.
>>
>> Also types can have extra parentheses that are useless like:
>> int (((a)));
>
> Most languages will allow (((a))) in expressions too; it is not unusual.
>
> What's different with C is treating a type specification as though it
> was an expression too, which can be confusing if you come across it
> unexpectedly. So:
>
> f(x);
>
> looks like a function call, but could equally be declaring 'x' of type
> 'f', depending on what 'f' actually is.

Similarly:

(f)(x)

can be casting (x) to type f, or calling f(x).

> Mixing up expression syntax and type syntax was deliberate, but also a
> mistake.

They aren't deep abiguities in the sense that while scanning the f
token, we can resolve it by looking up f, and giving it a token category
like "type-name" versus "identifier". Then the parser just has rules
that involve "type-name".

Still, anyone who just wants an accurate C parser has to implement
declarations, which is annoying.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
>
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>> typedef long int integer;
>> typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now; I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more
>> lax).
>
> I doubt it has ever been legal. Even K&R1 has the wording that rules it
> out. Pre-K&R1 C might have been more lax, but for most of the time
> before K&R1 C did not even have unsigned!

Or typedef.

The 1975 C reference manual has neither typedef nor unsigned (nor long,
nor short). K&R1 (1978) has both. I don't know which was added first.

> I wonder what else this generous compiler permitted. Could one do
>
> typedef double number;
> typedef long number hi_prec_num;
>
> for example? I doubt it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
> typedef long int integer;
> typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more
> lax).

Apparently it was never documented as legal. A compiler that accepted
it presumably had a bug (or perhaps an extension). (1983 was 5 years
after K&R1, which apparently made it clear that it's invalid.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Tuesday, December 13, 2022 at 3:07:46 PM UTC-3, Kaz Kylheku wrote:
> On 2022-12-13, Bart <b...@freeuk.com> wrote:
> > On 13/12/2022 14:46, Thiago Adams wrote:
> >> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
> >> ...
> >>> I think this is one of the biggest problem of C.. but this bothers more implementers.
> >>
> >> The data representation of C types are incredible complex.
> >>
> >> Also types can have extra parentheses that are useless like:
> >> int (((a)));
> >
> > Most languages will allow (((a))) in expressions too; it is not unusual.
> >
> > What's different with C is treating a type specification as though it
> > was an expression too, which can be confusing if you come across it
> > unexpectedly. So:
> >
> > f(x);
> >
> > looks like a function call, but could equally be declaring 'x' of type
> > 'f', depending on what 'f' actually is.
> Similarly:
>
> (f)(x)
>
> can be casting (x) to type f, or calling f(x).
> > Mixing up expression syntax and type syntax was deliberate, but also a
> > mistake.
> They aren't deep abiguities in the sense that while scanning the f
> token, we can resolve it by looking up f, and giving it a token category
> like "type-name" versus "identifier". Then the parser just has rules
> that involve "type-name".
>
> Still, anyone who just wants an accurate C parser has to implement
> declarations, which is annoying.

The problem is not only parsing..it is type manipulation.
imagine to calculate the size of sizeof(f)

void (*f[10])(int a[2], void (*pf)(int));

On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
> typedef long int integer;
> typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more lax).

Overall it seems to be "cutting edge" C for the time AFAICT.
New types are used all over to convey semantic information
about the variable that also makes the selection of the concrete
type very DRY.

Very surprising to me is the use of linked lists for the basic stacks.
Since the original application in the Apple Laserwriter was very
memory constrained, it's surprising that they spent the size of an
extra pointer on every stack element. Even unused elements have
this pointer, being linked together on their own per stack free list.

OTOH this would make it easy to initialize the stacks to use whatever
odd space was available after making big contiguous memory areas
for other stuff. You just carve up little (next pointer, object} nodes from
the desired memory and link them together into the free list.

So maybe the memory contraints encouraged this choice even though
it appears surprising that the famous "stack based language" does not
in fact use "stacks" per se.

luser droog <luser.droog@gmail.com> writes:

> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>> typedef long int integer;
>> typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now; I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>
> Overall it seems to be "cutting edge" C for the time AFAICT.
> New types are used all over to convey semantic information
> about the variable that also makes the selection of the concrete
> type very DRY.
>
> Very surprising to me is the use of linked lists for the basic stacks.
> Since the original application in the Apple Laserwriter was very
> memory constrained, it's surprising that they spent the size of an
> extra pointer on every stack element. Even unused elements have
> this pointer, being linked together on their own per stack free list.
>
> OTOH this would make it easy to initialize the stacks to use whatever
> odd space was available after making big contiguous memory areas
> for other stuff. You just carve up little (next pointer, object} nodes from
> the desired memory and link them together into the free list.

That's the key. It's simple.

About that time I visited a research lab developing cutting edge
distributed systems. Around the lab the team had pinned a huge banner
bearing the words "MEMORY IS CHEAP". When I asked about this (because
memory was /not/ cheap or plentiful in most systems at the time) I was
told that, because it /will/ be cheap and plentiful, cutting edge
software should not waste time solving a problem that will vanish by
release 2.0 (or in some cases even by the first release).

> So maybe the memory contraints encouraged this choice even though
> it appears surprising that the famous "stack based language" does not
> in fact use "stacks" per se.

What then, to your mind, is a stack?

--
Ben.

On 12/14/2022 12:59 PM, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
>
>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>> I was looking at the 1983 C sources of PostScript (via
>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>>
>>> It uses typedef like this:
>>>
>>> typedef long int integer;
>>> typedef unsigned integer Offset;
>>>
>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>>> than any of 'char short int long'.
>>>
>>> I guess this is not legal C now; I just wondered at what point it
>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>
>> Overall it seems to be "cutting edge" C for the time AFAICT.
>> New types are used all over to convey semantic information
>> about the variable that also makes the selection of the concrete
>> type very DRY.
>>
>> Very surprising to me is the use of linked lists for the basic stacks.
>> Since the original application in the Apple Laserwriter was very
>> memory constrained, it's surprising that they spent the size of an
>> extra pointer on every stack element. Even unused elements have
>> this pointer, being linked together on their own per stack free list.
>>
>> OTOH this would make it easy to initialize the stacks to use whatever
>> odd space was available after making big contiguous memory areas
>> for other stuff. You just carve up little (next pointer, object} nodes from
>> the desired memory and link them together into the free list.
>
> That's the key. It's simple.
>
> About that time I visited a research lab developing cutting edge
> distributed systems. Around the lab the team had pinned a huge banner
> bearing the words "MEMORY IS CHEAP". When I asked about this (because
> memory was /not/ cheap or plentiful in most systems at the time) I was
> told that, because it /will/ be cheap and plentiful, cutting edge
> software should not waste time solving a problem that will vanish by
> release 2.0 (or in some cases even by the first release).
>
>> So maybe the memory contraints encouraged this choice even though
>> it appears surprising that the famous "stack based language" does not
>> in fact use "stacks" per se.
>
> What then, to your mind, is a stack?
>

LIFO. Yes it can be created in thread "local" memory. I did one where
thread local memory was used to simulate a shared memory system. Back on
Quadros, iirc. A region allocator on the threads "stack" can be very
useful...

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

https://pastebin.com/raw/f37a23918

Some old experimental code of mine. 2009, how time goes by. wow.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 12/14/2022 12:59 PM, Ben Bacarisse wrote:
>> luser droog <luser.droog@gmail.com> writes:
>>
>>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>>> I was looking at the 1983 C sources of PostScript (via
>>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>>>
>>>> It uses typedef like this:
>>>>
>>>> typedef long int integer;
>>>> typedef unsigned integer Offset;
>>>>
>>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>>>> than any of 'char short int long'.
>>>>
>>>> I guess this is not legal C now; I just wondered at what point it
>>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>>
>>> Overall it seems to be "cutting edge" C for the time AFAICT.
>>> New types are used all over to convey semantic information
>>> about the variable that also makes the selection of the concrete
>>> type very DRY.
>>>
>>> Very surprising to me is the use of linked lists for the basic stacks.
>>> Since the original application in the Apple Laserwriter was very
>>> memory constrained, it's surprising that they spent the size of an
>>> extra pointer on every stack element. Even unused elements have
>>> this pointer, being linked together on their own per stack free list.
>>>
>>> OTOH this would make it easy to initialize the stacks to use whatever
>>> odd space was available after making big contiguous memory areas
>>> for other stuff. You just carve up little (next pointer, object} nodes from
>>> the desired memory and link them together into the free list.
>>
>> That's the key. It's simple.
>> About that time I visited a research lab developing cutting edge
>> distributed systems. Around the lab the team had pinned a huge banner
>> bearing the words "MEMORY IS CHEAP". When I asked about this (because
>> memory was /not/ cheap or plentiful in most systems at the time) I was
>> told that, because it /will/ be cheap and plentiful, cutting edge
>> software should not waste time solving a problem that will vanish by
>> release 2.0 (or in some cases even by the first release).
>>
>>> So maybe the memory contraints encouraged this choice even though
>>> it appears surprising that the famous "stack based language" does not
>>> in fact use "stacks" per se.
>>
>> What then, to your mind, is a stack?
>
> LIFO.

Sure, but since you didn't dispute that the linked list used by this C
code is a stack "per se", there was really no need to confirm your
position.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>luser droog <luser.droog@gmail.com> writes:
>
>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>> I was looking at the 1983 C sources of PostScript (via
>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>>
>>> It uses typedef like this:
>>>
>>> typedef long int integer;
>>> typedef unsigned integer Offset;
>>>
>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>>> than any of 'char short int long'.
>>>
>>> I guess this is not legal C now; I just wondered at what point it
>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>
>> Overall it seems to be "cutting edge" C for the time AFAICT.
>> New types are used all over to convey semantic information
>> about the variable that also makes the selection of the concrete
>> type very DRY.
>>
>> Very surprising to me is the use of linked lists for the basic stacks.
>> Since the original application in the Apple Laserwriter was very
>> memory constrained, it's surprising that they spent the size of an
>> extra pointer on every stack element. Even unused elements have
>> this pointer, being linked together on their own per stack free list.
>>
>> OTOH this would make it easy to initialize the stacks to use whatever
>> odd space was available after making big contiguous memory areas
>> for other stuff. You just carve up little (next pointer, object} nodes from
>> the desired memory and link them together into the free list.
>
>That's the key. It's simple.
>
>About that time I visited a research lab developing cutting edge
>distributed systems. Around the lab the team had pinned a huge banner
>bearing the words "MEMORY IS CHEAP". When I asked about this (because
>memory was /not/ cheap or plentiful in most systems at the time) I was
>told that, because it /will/ be cheap and plentiful, cutting edge
>software should not waste time solving a problem that will vanish by
>release 2.0 (or in some cases even by the first release).

Was that lab in San Jose? We used a similar motto extensively when
developing our cutting edge distributed system (1989-1997).

"Memory is not a problem".

scott@slp53.sl.home (Scott Lurndal) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>luser droog <luser.droog@gmail.com> writes:
>>
>>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>>> I was looking at the 1983 C sources of PostScript (via
>>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>>>
>>>> It uses typedef like this:
>>>>
>>>> typedef long int integer;
>>>> typedef unsigned integer Offset;
>>>>
>>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>>>> than any of 'char short int long'.
>>>>
>>>> I guess this is not legal C now; I just wondered at what point it
>>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>>
>>> Overall it seems to be "cutting edge" C for the time AFAICT.
>>> New types are used all over to convey semantic information
>>> about the variable that also makes the selection of the concrete
>>> type very DRY.
>>>
>>> Very surprising to me is the use of linked lists for the basic stacks.
>>> Since the original application in the Apple Laserwriter was very
>>> memory constrained, it's surprising that they spent the size of an
>>> extra pointer on every stack element. Even unused elements have
>>> this pointer, being linked together on their own per stack free list.
>>>
>>> OTOH this would make it easy to initialize the stacks to use whatever
>>> odd space was available after making big contiguous memory areas
>>> for other stuff. You just carve up little (next pointer, object} nodes from
>>> the desired memory and link them together into the free list.
>>
>>That's the key. It's simple.
>>
>>About that time I visited a research lab developing cutting edge
>>distributed systems. Around the lab the team had pinned a huge banner
>>bearing the words "MEMORY IS CHEAP". When I asked about this (because
>>memory was /not/ cheap or plentiful in most systems at the time) I was
>>told that, because it /will/ be cheap and plentiful, cutting edge
>>software should not waste time solving a problem that will vanish by
>>release 2.0 (or in some cases even by the first release).
>
> Was that lab in San Jose? We used a similar motto extensively when
> developing our cutting edge distributed system (1989-1997).
>
> "Memory is not a problem".

No, Pittsburgh :-(

--
Ben.

On Wednesday, December 14, 2022 at 2:59:42 PM UTC-6, Ben Bacarisse wrote:
> luser droog <luser...@gmail.com> writes:
>
> > Very surprising to me is the use of linked lists for the basic stacks.
> > Since the original application in the Apple Laserwriter was very
> > memory constrained, it's surprising that they spent the size of an
> > extra pointer on every stack element. Even unused elements have
> > this pointer, being linked together on their own per stack free list.
> >
> > OTOH this would make it easy to initialize the stacks to use whatever
> > odd space was available after making big contiguous memory areas
> > for other stuff. You just carve up little (next pointer, object} nodes from
> > the desired memory and link them together into the free list.
> That's the key. It's simple.
>
> About that time I visited a research lab developing cutting edge
> distributed systems. Around the lab the team had pinned a huge banner
> bearing the words "MEMORY IS CHEAP". When I asked about this (because
> memory was /not/ cheap or plentiful in most systems at the time) I was
> told that, because it /will/ be cheap and plentiful, cutting edge
> software should not waste time solving a problem that will vanish by
> release 2.0 (or in some cases even by the first release).
> > So maybe the memory contraints encouraged this choice even though
> > it appears surprising that the famous "stack based language" does not
> > in fact use "stacks" per se.
> What then, to your mind, is a stack?
>

I'd have expected to see a single TOS pointer ranging over a contiguous
set of addresses. An array representation. I also expected this because
the existing PostScript operators that copy stacks, viz. `execstack`
and `dictstack` both return their data in a (caller supplied) array.

So, the existing interfaces only present array data. And a single
pointer and a packed array are the obvious "minimal space" representation.

Then again, the code we have is from '83, so maybe they were still a few
months away from trying to fit it onto a ROM.

luser droog <luser.droog@gmail.com> writes:

> On Wednesday, December 14, 2022 at 2:59:42 PM UTC-6, Ben Bacarisse wrote:
>> luser droog <luser...@gmail.com> writes:
>>
>> > Very surprising to me is the use of linked lists for the basic stacks.
>> > Since the original application in the Apple Laserwriter was very
>> > memory constrained, it's surprising that they spent the size of an
>> > extra pointer on every stack element. Even unused elements have
>> > this pointer, being linked together on their own per stack free list.
>> >
>> > OTOH this would make it easy to initialize the stacks to use whatever
>> > odd space was available after making big contiguous memory areas
>> > for other stuff. You just carve up little (next pointer, object} nodes from
>> > the desired memory and link them together into the free list.
>> That's the key. It's simple.
>>
>> About that time I visited a research lab developing cutting edge
>> distributed systems. Around the lab the team had pinned a huge banner
>> bearing the words "MEMORY IS CHEAP". When I asked about this (because
>> memory was /not/ cheap or plentiful in most systems at the time) I was
>> told that, because it /will/ be cheap and plentiful, cutting edge
>> software should not waste time solving a problem that will vanish by
>> release 2.0 (or in some cases even by the first release).
>> > So maybe the memory contraints encouraged this choice even though
>> > it appears surprising that the famous "stack based language" does not
>> > in fact use "stacks" per se.
>> What then, to your mind, is a stack?
>
> I'd have expected to see a single TOS pointer ranging over a contiguous
> set of addresses.

I got that from your earlier remark. I wondered why you thought a
linked list was not a stack "per se".

> An array representation. I also expected this because
> the existing PostScript operators that copy stacks, viz. `execstack`
> and `dictstack` both return their data in a (caller supplied) array.

That might be a big win if the result can be shared, but it's possible
it needs to be copied anyway. I really don't remember.

> So, the existing interfaces only present array data. And a single
> pointer and a packed array are the obvious "minimal space"
> representation.
>
> Then again, the code we have is from '83, so maybe they were still a few
> months away from trying to fit it onto a ROM.

The stack won't be in ROM anyway and the /code/ to manage either kind of
stack will be small.

--
Ben.

Am 13.12.2022 um 14:45 schrieb Bart:
> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
>   typedef long int integer;
>   typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more lax).

The proper solution is:

#include <type_traits>

using X = unsigned;
using Y = std::make_signed_t<X>;

Maybe they didn't knew that in 1983. ;-)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bart <bc@freeuk.com> writes:
>
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>> typedef long int integer;
>> typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now; I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more
>> lax).
>
> I doubt it has ever been legal. Even K&R1 has the wording that rules it
> out. Pre-K&R1 C might have been more lax, but for most of the time
> before K&R1 C did not even have unsigned!
>
> I wonder what else this generous compiler permitted. Could one do
>
> typedef double number;
> typedef long number hi_prec_num;
>
> for example? I doubt it.

Most likely the issue is not the compiler but the code. This
body of code has all sorts of problems, including syntax errors
and some things that are obviously wrong or incomplete. If you
try compiling it I think you'll see what I mean.

Incidentally, there are pretty clear signs of a Mesa influence,
which isn't surprising since the principals came from Xerox PARC.

In article <tnjp2u$3juvv$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
....
>A stupid solution is:
>
>#include <type_traits>
>
>using X = unsigned;
>using Y = std::make_signed_t<X>;
>
>Maybe they didn't knew that in 1983. ;-)
>

Could you also give us a solution in Basic+?

How about Intercal?

Thanks.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/LadyChatterley