5 ms·

Interesting usage of "extern" and "auto". Quite different from contemporary C: tree() { extern symbol, block, csym[], ctyp, isn, peeksym, o

Interesting usage of "extern" and "auto". Quite different from contemporary C: tree() { extern symbol, block, csym[], ctyp, isn, peeksym, opdope[], build, error, cp[], cmst[], space, ospace, cval, ossiz, exit, errflush, cmsiz; auto op[], opst[20], pp[], prst[20], andflg, o, p, ps, os; ... Looks like "extern" is used to bring global symbols into function scope. Everything looks to be "int" by default. Some array declarations are specifying a size, others are not. Are the "sizeless" arrays meant to be used as pointers only?

Joker_vD 2y ago
Yes, pretty much. To be fair, C at this point was basically BCPL with slightly different syntax (and better char/string support). The introduction of structs (and then longs) changed it forever.
- kragen 2y ago
  BCPL had a lot of features C didn't have at this point and still doesn't. You mean B.
  - Joker_vD 2y ago
    Could you elaborate on those features? From the top of my head, those are: nested functions — those always were of dubious usefulness compared to the implementation difficulties needed; labels are actual constants, so computed GOTO is available — that's definitely a feature standard C still doesn't have; manifest constants — this one is Ritchie's most baffling omission in the language; multiple assignment — it's not actually parallel so merely a syntax nicety (with a footgun loaded); valof-resultis — while very nice, it's also merely a syntax nicety, "lvalue := valof (... resultis expr; ...)" is the same as "{... lvalue = expr; goto after; ... } after: ;". What else is there? Pointless distinction between the declaration syntax of functions and procedures?
    - kragen 2y ago
      That includes everything I was thinking of and several things I didn't know about.
  - psjs 2y ago
    What features did BCPL have at that point that C didn’t have (and stil does not)?
netbsdusers 2y ago
You can do the same with a modren C compiler - the extern and auto mean the same and int is still the default type.
- tialaramex 2y ago
  In C23, auto doesn't have a default type, if you write auto without a type then you get the C++ style "type deduction" instead. This is part of the trend (regretted by some WG14 members) of WG14 increasingly serving as a way to fix the core of C++ by instead mutating the C language it's ostensibly based on. You can think of deduction as crap type inference.
  - pjmlp 2y ago
    Design by committee, the outcome is usually not what the people on the trenches would like to get.
    - uecker 2y ago
      Nobody in the trenches seemed to use old-style auto in the last decades. BTW: The right place to complain if you disagree would be the compiler vendors. In particular the Clang side pushes very much for keeping C and C++ aligned, because they have a shared C/C++ FE. So if you want something else, please file or comment on bugs in their bug tracker. Similar for other compilers.
      - Y_Y 2y ago
        > Nobody in the trenches seemed to use old-style auto in the last decades. To the beat of my knowledge, there was no case where "auto" wasn't redundant. See e.g. https://stackoverflow.com/a/2192761 https://stackoverflow.com/a/2192761 This makes me feel better about repurposing it, but I still hate the shitty use it's been put to.
        saagarjha 2y ago
        What's your better use for it, then?
fsckboy 2y ago
>Looks like "extern" is used to bring global symbols into function scope. a better way to think of extern is, "this symbol is not declared/defined/allocated here, it is declared/defined/allocated someplace else" "this is its type so your code can reference it properly, and the linker will match up your references with the declared/defined/allocated storage later" (i'm using reference in the generic english sense, not pointer or anything. it's "that which can give you not only an r-value but an l-value")
dfawcus 2y ago
As to "sizeless" arrays - yes. Have a look at the early history of C document on DMR's site, it mentions that the initial syntax for pointers was that form.
xenadu02 2y ago
"auto" used to mean automatic memory management because if you are coming from assembly or even some other older higher-level languages you can't just declare a local variable and use it as you please. You must declare somewhere to store it and manage its lifetime (even if that means everything is global). C and its contemporaries introduced automatic or in modern terms local or stack allocated values, often with lexically-scoped lifetimes. extern meaning something outside this file declares the storage for it and register meaning the compiler should keep the value in a register. However auto has always been the default and thus redundant and style-wise almost no one ever had the style of explicitly specifying auto so it was little-used in the wild. So the C23 committee adopted auto to mean the same as C++: automatically infer the type of the declaration. You can see some of B's legacy in the design of C. Making everything int by default harkens back to B's lack of types because everything was a machine word you could interpret however you wanted. Also with original C's function declarations which don't really make sense. The prototype only declares the name and the local function definition then defines (between the closing paren and the opening brace) the list of parameters and their types. There was no attempt whatsoever to have the compiler verify you passed the correct number or types of parameters.
HarHarVeryFunny 2y ago
Declaring a variable or function as extern(al) just tells the compiler to assume that it is defined "externally", i.e. in another source file. The compiler will generate references to the named variable/function, and the linker will substitute the actual address of the variable/function when linking all the object files together. Modern C won't let you put extern declarations inside a function like this, basically because it's bad practice and makes the code less readable. You can of course still put them at global scope (e.g. at top of the source file), but better to put them into a header file, with your code organized into modules of paired .h definition and .c implementation files.
int_19h 2y ago
All of these things come directly from B: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bintro.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bintr...

Joker_vD 2y ago

Yes, pretty much. To be fair, C at this point was basically BCPL with slightly different syntax (and better char/string support). The introduction of structs (and then longs) changed it forever.

kragen 2y ago
BCPL had a lot of features C didn't have at this point and still doesn't. You mean B.
- Joker_vD 2y ago
  Could you elaborate on those features? From the top of my head, those are: nested functions — those always were of dubious usefulness compared to the implementation difficulties needed; labels are actual constants, so computed GOTO is available — that's definitely a feature standard C still doesn't have; manifest constants — this one is Ritchie's most baffling omission in the language; multiple assignment — it's not actually parallel so merely a syntax nicety (with a footgun loaded); valof-resultis — while very nice, it's also merely a syntax nicety, "lvalue := valof (... resultis expr; ...)" is the same as "{... lvalue = expr; goto after; ... } after: ;". What else is there? Pointless distinction between the declaration syntax of functions and procedures?
  - kragen 2y ago
    That includes everything I was thinking of and several things I didn't know about.
- psjs 2y ago
  What features did BCPL have at that point that C didn’t have (and stil does not)?

netbsdusers 2y ago

You can do the same with a modren C compiler - the extern and auto mean the same and int is still the default type.

tialaramex 2y ago
In C23, auto doesn't have a default type, if you write auto without a type then you get the C++ style "type deduction" instead. This is part of the trend (regretted by some WG14 members) of WG14 increasingly serving as a way to fix the core of C++ by instead mutating the C language it's ostensibly based on. You can think of deduction as crap type inference.
- pjmlp 2y ago
  Design by committee, the outcome is usually not what the people on the trenches would like to get.
  - uecker 2y ago
    Nobody in the trenches seemed to use old-style auto in the last decades. BTW: The right place to complain if you disagree would be the compiler vendors. In particular the Clang side pushes very much for keeping C and C++ aligned, because they have a shared C/C++ FE. So if you want something else, please file or comment on bugs in their bug tracker. Similar for other compilers.
    - Y_Y 2y ago
      > Nobody in the trenches seemed to use old-style auto in the last decades. To the beat of my knowledge, there was no case where "auto" wasn't redundant. See e.g. https://stackoverflow.com/a/2192761 https://stackoverflow.com/a/2192761 This makes me feel better about repurposing it, but I still hate the shitty use it's been put to.
      - saagarjha 2y ago
        What's your better use for it, then?

fsckboy 2y ago

>Looks like "extern" is used to bring global symbols into function scope. a better way to think of extern is, "this symbol is not declared/defined/allocated here, it is declared/defined/allocated someplace else" "this is its type so your code can reference it properly, and the linker will match up your references with the declared/defined/allocated storage later" (i'm using reference in the generic english sense, not pointer or anything. it's "that which can give you not only an r-value but an l-value")

dfawcus 2y ago

As to "sizeless" arrays - yes. Have a look at the early history of C document on DMR's site, it mentions that the initial syntax for pointers was that form.

xenadu02 2y ago

"auto" used to mean automatic memory management because if you are coming from assembly or even some other older higher-level languages you can't just declare a local variable and use it as you please. You must declare somewhere to store it and manage its lifetime (even if that means everything is global). C and its contemporaries introduced automatic or in modern terms local or stack allocated values, often with lexically-scoped lifetimes. extern meaning something outside this file declares the storage for it and register meaning the compiler should keep the value in a register. However auto has always been the default and thus redundant and style-wise almost no one ever had the style of explicitly specifying auto so it was little-used in the wild. So the C23 committee adopted auto to mean the same as C++: automatically infer the type of the declaration. You can see some of B's legacy in the design of C. Making everything int by default harkens back to B's lack of types because everything was a machine word you could interpret however you wanted. Also with original C's function declarations which don't really make sense. The prototype only declares the name and the local function definition then defines (between the closing paren and the opening brace) the list of parameters and their types. There was no attempt whatsoever to have the compiler verify you passed the correct number or types of parameters.

HarHarVeryFunny 2y ago

Declaring a variable or function as extern(al) just tells the compiler to assume that it is defined "externally", i.e. in another source file. The compiler will generate references to the named variable/function, and the linker will substitute the actual address of the variable/function when linking all the object files together. Modern C won't let you put extern declarations inside a function like this, basically because it's bad practice and makes the code less readable. You can of course still put them at global scope (e.g. at top of the source file), but better to put them into a header file, with your code organized into modules of paired .h definition and .c implementation files.

int_19h 2y ago

All of these things come directly from B: https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bintro.html https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bintr...