how do you identify what are the preprocessor and macros in c program

[brucehoult]

The standard functions Ord and Ptr provide direct control of the address contained in a pointer. Ord returns the address contained in its pointer argument as an Integer, and Ptr converts its Integer argument into a pointer which is compatible with all pointer types.

I didn't say there are no pointers, I said there is no easy-Unions like in C, and in general, in Pascal you need more effort to get the same result.

A Pascal-union-like is called "case inside a record", it makes it possible to give a variable multiple types.

Yes, I'm perfectly aware of Pascal variant records. I used Pascal professionally as my main language for about ten years.

It's not safe

Neither are C unions. That's the whole point. You can use them for exactly the same tricks.

In some Pascal implementations you have to change the selector field in order to not get an error when accessing an aliased field. So you change the selector. It never hurts to do so anyway.

I theory, perhaps some conforming implementation could zero out the other fields when you change the selector, but I've never see that happen. The raw bits are still there, and can be accessed via the alternate field names.

As I said, C and Pascal are almost totally interchangeable.

Sometimes you need to type a little more code in Pascal but the generated machine code and runtime results are equivalent.

By far the biggest difference is that C/C++ don't have lexically nested functions with the ability to access outer function local variables from inner functions -- even when the inner function is passed to a yet another function (e.g. qsort()).

But gcc and clang implement that in C anyway, as an extension.

Another difference is that Pascal typically allows you to directly do boolean AND, OR, bit set/clear/test on bit vectors of at least 256 or 512 bits, under the type "set of ...". In C you need to explicitly create and array of char or int (etc) and write some loops or div/mod and shift.

Again, the generated machine code is exactly the same in the end.

[SiliconWizard]

What  exactly is an "easy union" compared to variant records?

[Nominal Animal]

I often run
    gcc -Wall -dM -E source-files... | sort
to obtain the list of all preprocessor macros that apply when compiling source-files....

I also use the Pre-defined Compiler Macros wiki, to look for preprocessor macros that let me create portability workarounds or optimized versions for specific hardware/OS/compiler/C library combinations.

As illustrated by the above discussion, there are strong opinions regarding preprocessor macros.  Whether you can rely on them (consider e.g. C11 6.5.1.1 _Generic() selections), or you need to avoid them, depends on external reasons.  Those external reasons can be standards like MISRA C, company or organization coding conventions, and so on.

Because C itself does not force anything with respect to preprocessor macros, it is up to us humans to deal with it.  The most common approach is to use all UPPERCASE names (with underscores _ replacing spaces) for only preprocessor macros.  If you use an advanced source code editor, it can usually help with this kind of stuff.

Me, I try to go with the principle of least surprise, unix philosophy, and POSIX; the important/meaningful exceptions to the "uppercase thing is a macro; macros are in all uppercase" rule are so few one can actually remember them all: FILE (is a type and not a macro); getc() and getchar(), and putc() and putchar(), all four of which may be macros that evaluate the stream argument (the FILE pointer parameter) more than once.  There are a few additional ones, but these five are the important ones.

[DiTBho]

Code: [Select]

OType = (type1, type2, type3);

OMe = record
  case myType: OType of //<-------------- this is a union-like in Pascal
    type1: (w1: Integer);
    type2: (w2: Integer);
    type3: (w3: Integer);
end;


Code: [Select]

var
  O: OMe;
begin
  O.myType := Type1;
  O.w1 := 1; // this is ok!
  O.w2 := 666; //<-------- There is no w2 for Type1, w2 belongs to Type2!
end.


Code: [Select]

typedef union
{
    struct
    {
        uint32_t w1;
    } type1;
    struct
    {
        uint32_t w2;
    } type2;
    struct
    {
        uint32_t w3;
    } type3;
} OMe_t;


Code: [Select]

void foo()
{
    OMe_t O;

    O.type1.w1 = 1;
    O.type1.w2 = 666; // <-------- There is no w2 for Type1, w2 belongs to Type2!
}

Turbo Pascal v7 (embedded inside DoxBox on a Linux machine)

Code: [Select]

compiling foo.pas ... done
(no error)

C (Gcc on a Linux machine)

Code: [Select]

compiling foo.c ... failed
foo.c:25: error: 'struct <anonymous>' has no member named 'w2'

Conclusion: unions in C are by - de fact - simpler to check in C than in Pascal.

[brucehoult]

Turbo Pascal v7 (embedded inside DoxBox on a Linux machine)

Code: [Select]

compiling foo.pas ... done
(no error)

OK, so TP doesn't check the current variant. It's allowed to not check, but just to be (un)safe you can do O.myType := Type2 before trying to access w2, and it will work also on compilers that do check.

C (Gcc on a Linux machine)

Code: [Select]

compiling foo.c ... failed
foo.c:25: error: 'struct <anonymous>' has no member named 'w2'

Conclusion: unions in C are by - de fact - simpler to check in C than in Pascal.

This is stupid. Obviously you need to write O.type2.w2 = 666 if you want to get or set field w2.

You can equally easily use variant records in Pascal and unions in C to do unsafe typecasting when you want to. Which is the point -- everything you can do in C, you can also do in Pascal.

In fact Pascal has the advantage here because in C you can't tell which union member you should use.

Let's add a procedure printOme(O : Ome) and function void printOme(OMe_t O) that print the correct current field in the data passed to them.

(This is a dumb example because w1, w2, w3 all have the same type, so it doesn't matter, but whatever ... assume one of them is a float and maybe another is a char)

In Pascal:

Code: [Select]

procedure printOme(O : Ome)
begin
  case O.myType of
    type1: WriteLn(O.w1);
    type2: WriteLn(O.w2);
    type3: WriteLn(O.w3)
  end
end

var
  O: OMe;
begin
  O.myType := Type1;
  O.w1 := 1;
  printOme(O);
  O.myType := Type2;
  O.w2 := 666;
  printOme(O);
end.

And in C...

Code: [Select]

void printOme(OMe_t O){
  // ?????
  printf("%d\n", O.type1.w1);
  printf("%d\n", O.type2.w2);
  printf("%d\n", O.type3.w3);
}

void foo()
{
    OMe_t O;

    O.type1.w1 = 1;
    primtOme(O);
    O.type2.w2 = 666;
    primtOme(O);
}

How do you decide which one to print in the C version?

Answer: you can't.


Of course, since Pascal and C are equivalent, you *can* do this, with extra work, by defining an OType enum and wrapping the union in a struct with an extra myType field. And then in printOme do a switch on the myType field.

[SiliconWizard]

you *can* do this, with extra work, by defining an OType enum and wrapping the union in a struct with an extra myType field. And then in printOme do a switch on the myType field.

Of course. That's what you usually do one way or another, unless you love shooting yourself in the foot.

[brucehoult]

you *can* do this, with extra work, by defining an OType enum and wrapping the union in a struct with an extra myType field. And then in printOme do a switch on the myType field.

Of course. That's what you usually do one way or another, unless you love shooting yourself in the foot.

Exactly.

And in case anyone wants to say "Oh, but Pascal and C aren't equivalent because if you somehow know from some other means which variant is the current one then you don't have to have the wasted storage for the type tag field".

No .. in Pascal the type of the selector is required when you declare the variant record type, but the selector name (and the colon) are not. In which case it isn't stored.

In general, I stand by my assertion that the standardised preprocessor is the only important distinguishing feature between Pascal and C.

[SiliconWizard]

In general, I stand by my assertion that the standardised preprocessor is the only important distinguishing feature between Pascal and C.

Well, I don't quite agree, but that's a matter of perspective.

I mentioned functions/procedures as parameters, you corrected me saying that they were in the Pascal definition, and I'll believe you. I didn't check. (I admit I never read the official specs of Pascal, contrary to the later Oberon and even  - out of curiosity - Modula 3.) I admit I mostly used TP back then, and it didn't implement them. So anyway, let's cross that out.

But there was the matter of separate compilation. I don't think the original spec defined that, but apparently UCSD Pascal was the first defining "units", so that part was long existing too. (And in a better form than just includes.) TP didn't implement this until later versions.

So yeah, not much left missing? IIRC, you could even do conditional compilation in most Pascal compilers with "directives".

Now, outside of unions (for which I agree with you), C still was easier to use for accessing "memory" through structures than Pascal.
I don't think you could, for instance, define the memory location of a record and then access its fields to access particular memory locations as you could do with C. While the equivalent in Pascal was possible, it was not as "elegant" (that may be a matter of taste.) But here again, maybe you have a better memory and command of Pascal, and maybe that was just as easy?

Ultimately, as for later Wirth languages, the real problem was not the language itself, but the lack of existing tools for a large range of platforms.
The reason for this is a complex one - we can refer to our discussions about what makes a language popular or not. Its technical merits are most often marginal for explaining popularity.

An interesting example was Modula-3. It was *the* descendant of a wirthian language that was carefully defined by a group of industry professionals. It was fully usable, and in many aspects, would definitely still be. The tools were very few though. CM3 which was one of the few has known some kind of rebirth: https://github.com/modula3/cm3

One could also say that Ada is a descendant of those wirthian languages, and Ada is still alive and kicking, even though it's still in niche applications.

[DiTBho]

outside of unions (for which I agree with you), C still was easier to use for accessing "memory" through structures than Pascal.

Precisely! Plus, easier for the ICE, therefore easier for debugging, which is what I care most about everything.

[SiliconWizard]

outside of unions (for which I agree with you), C still was easier to use for accessing "memory" through structures than Pascal.

Precisely! Plus, easier for the ICE, therefore easier for debugging, which is what I care most about everything.

To be fair - I don't remember all the details of Pascal, haven't used it in ages, so I need to brush up! Taking what Bruce said:

Ptr converts its Integer argument into a pointer which is compatible with all pointer types.

Defining a pointer to a record at a specific address should be trivial in Pascal. So, contrary to what I said, this should be no problem at all.

Debugging is a different issue if you consider tools. The fact there were more tools for C does not mean C was better than Pascal. It's just a popularity problem, as I mentioned earlier, not a technical issue.

So now, I'll just have to agree with Bruce. There was no sizeable difference between Pascal and C, apart from the preprocessor. The only difference that really mattered for developers, as you yourself noted,  were the tools available. But the language itself certainly never prevented such tools to exist. A number of compilers, TP being the most popular, actually lacked some features because they were meant to be simple - TP 3.0 just fit within about 30 KBytes on CP/M, with an integrated editor!

Getting to understand why some languages become more popular than others is a complex matter, which we have talked about in numerous threads already. The causes are complex to understand, and again the technical merits are often just a marginal point. But once a language becomes popular, the ecosystem grows, there's a lot more tools, libraries, etc, available, and so that reinforces the popularity.

One point that could explain the lack of debugging tools for Pascal, even back at the time when it was moderatly popular, may also have something to do with a lack of... demand. Not to sound corny, but possibly stuff written in Pascal required a lot less "debugging" with low-level tools than stuff written in C. The fact you yourself once had this particular need can by no means be generalized.

[Rick Law]

I think by today hardly anyone develop commercial systems using Pascal.  By commercial systems I mean anything used in a product or business.  So, comparing Pascal and C is rather academic now.

Yeah C is not safe.  A hammer is not safe when used wrong.  We should think of it as the need to improve the quality of the users (programmers) rather than putting yet another layer of steel on the boots to prevent the user from shooting himself/herself on the foot.

So allow me to remind folks of an old saying: "When it is absolutely idiot proof, it would be so overburdened only idiots will use it..."

[brucehoult]

In general, I stand by my assertion that the standardised preprocessor is the only important distinguishing feature between Pascal and C.

Well, I don't quite agree, but that's a matter of perspective.

I mentioned functions/procedures as parameters, you corrected me saying that they were in the Pascal definition, and I'll believe you. I didn't check. (I admit I never read the official specs of Pascal, contrary to the later Oberon and even  - out of curiosity - Modula 3.) I admit I mostly used TP back then, and it didn't implement them. So anyway, let's cross that out.

But there was the matter of separate compilation. I don't think the original spec defined that, but apparently UCSD Pascal was the first defining "units", so that part was long existing too. (And in a better form than just includes.) TP didn't implement this until later versions.

Yes, that dates from 1977. VAX Pascal did something similar -- VMS allowed you to do separate compilation and mix object files from different compilers and languages right from the start.

So yeah, not much left missing? IIRC, you could even do conditional compilation in most Pascal compilers with "directives".

Yes. Not my experience was with DEC and Apple computers. I didn't use MS-DOS or Windows at all.

Apple Pascal (UCSD) and VAX Pascal had %include but not conditional compilation.

Apple Lisa Pascal had compile-time defines and conditional compilation. I've screenshotted the relevant page from the manual:

https://pbs.twimg.com/media/FNSYsAuaAAAUbhp.png

Full manual at https://archive.org/details/bitsavers_applelisawl3.0ReferenceManual1984_16927177/page/n151/mode/2up

Pascal compilers on the Macintosh followed Lisa Pascal. Early Macintosh apps (and the OS) were written and compiled on Lisa computers, using Lisa Pascal. So there is at least Macintosh Pascal (interpreted), THINK Pascal, MPW Pascal, Metroworks (CodeWarrior) Pascal. All maintained close source compatibility with Lisa Pascal, including conditional compilation.

There was a short-lived Mac version of Turbo Pascal which I believe only had include files not conditional compilation. Manual here:

https://winworldpc.com/download/73283e1b-9e4b-11e8-893a-fa163e9022f0

What was missing was macros, and in particular function-like macros.

Now, outside of unions (for which I agree with you), C still was easier to use for accessing "memory" through structures than Pascal.
I don't think you could, for instance, define the memory location of a record and then access its fields to access particular memory locations as you could do with C. While the equivalent in Pascal was possible, it was not as "elegant" (that may be a matter of taste.) But here again, maybe you have a better memory and command of Pascal, and maybe that was just as easy?

Not sure what you mean there. I believe I already showed how to do that in ...

https://www.eevblog.com/forum/programming/how-do-you-identify-what-are-the-preprocessor-and-macros-in-c-program/msg4045750/#msg4045750

That was making a pointer to a char point to an arbitrary place in memory, but it's just the same with a record.

[DiTBho]

Pointer to arbitrary place in memory work very good with the mentioned "unchecked converters". I haven't yet played with the Mikroe's Pic-Pascal, but years ago I used Turbo51, a Pascal compiler for intel51 chips in expanded mode (full 64Kbyte addressing space) on a weather station(1) powered by an enhanced 51 chip.

Turbo51 offered excellent code generation an optimization, it didn't offer any ICE support only source-level debugging with OMF object file, it means you have to pay for static-debugging tools, which is ok and fair, just a note: the weather-station-project was only partially written in Pascal, all the memory-side things (so through user-defined "unchecked converters") were written in Assembly.

[westfw]

Is “separate compilation units” really considered a feature of the “language”?
I would have thought it orthogonal, the way some assemblers support a linker, and some don’t.
I guess if you want to have the strong typing and range checking of something like pascal, you need an equivalent of “extern” that conveys all that in the absence of full source?

[brucehoult]

Is “separate compilation units” really considered a feature of the “language”?
I would have thought it orthogonal, the way some assemblers support a linker, and some don’t.
I guess if you want to have the strong typing and range checking of something like pascal, you need an equivalent of “extern” that conveys all that in the absence of full source?

Compilers for languages such as Pascal and the Modula family generally output two things: 1) an object file for the executable code, and 2) a "definition" file that contains all the type information for globally visible declarations. A binary equivalent of a C header file. Or pre-compiled header file.

[SiliconWizard]

Pascal units are like modules for other languages, they are DEFINITELY a feature of the language. Modules in general are not just object files that you happen to link.

For C, it could be argued that separate compilation is less of a feature of the language, but that still wouldn't be entirely true. The language has to define that global symbols (that aren't static) are "exported" in object files, otherwise separate compilation would never work. So even for such a basic support as in C, it IS a feature of the language.

[SiliconWizard]

Now, outside of unions (for which I agree with you), C still was easier to use for accessing "memory" through structures than Pascal.
I don't think you could, for instance, define the memory location of a record and then access its fields to access particular memory locations as you could do with C. While the equivalent in Pascal was possible, it was not as "elegant" (that may be a matter of taste.) But here again, maybe you have a better memory and command of Pascal, and maybe that was just as easy?

Not sure what you mean there. I believe I already showed how to do that in ...

Yes, I corrected that in a later post.
All in all, as I said, I think the restrictions were more due to available tools and what they implemented than to the language itself.

And there's been some kind of "battle" between C-like languages and "wirthian" languages for several decades. (I consider Ada a wirthian language.)
Common points made "against" wirthian languages is that they are seen as more "verbose" and more "rigid". Of course, some will see that as meaning more readable, more maintainable and "safer", while many tend to see this as just plain annoying and counter-productive. The latter seem to be the majority these days, but interestingly, those "arguments" are almost entirely subjective, while the former have at least some objective basis to them.

[westfw]

... the only important distinguishing feature between Pascal and C ...

It always worries me when the distinction between "a language as defined" and "particular implementations of the language" becomes blurred.  "BASIC is a fine language with modern structured programming constructs, compiled code, and optional line numbers - I don't see what people are complaining about!"
Pascal as defined by Wirth was perhaps so obviously useless that no one ever tried to develop actual products with it; it remained (?) confined to the educational uses it was aimed at.  I mean, no equivalent of fopen()??  "we'll just leave that all the the JCL?"  (but the BNF for the core lanaguage was sure pretty!)

One of my college projects involved adding formatted output to the Pascal compiler, because a lot of programming back then ended up wanting to output nice neat tables of numbers, just like Fortran could make.  There was never a thought that this could be written in Pascal itself, because user-level Pascal procedures could have a variable number of arguments (even though they were used by the Pascal IO procedures.)
I guess all that got fixed in the various real-world compilers.  Which is fine, but...

OTOH, I'm not sure that early C ever had a clear "definition."  By the time it escaped into the world at large, it instead essentially had a "reference implementation."  If you wanted to be a successful C compiler, you had better implement things the way the PDP/11 Unix Compiler did it.  "We'll define it later." (and they did.)  (I particularly remember the early implementations of VARARGS: "well, we know that the caller put all the arguments on the stack in THIS order, and everything is promoted to an int, so if we take the address of the last (or first) argument, we can point to things past that and there will be the additional arguments!")

[brucehoult]

Now, outside of unions (for which I agree with you), C still was easier to use for accessing "memory" through structures than Pascal.
I don't think you could, for instance, define the memory location of a record and then access its fields to access particular memory locations as you could do with C. While the equivalent in Pascal was possible, it was not as "elegant" (that may be a matter of taste.) But here again, maybe you have a better memory and command of Pascal, and maybe that was just as easy?

Not sure what you mean there. I believe I already showed how to do that in ...

Yes, I corrected that in a later post.

Yes, I've seen that now.

And there's been some kind of "battle" between C-like languages and "wirthian" languages for several decades. (I consider Ada a wirthian language.)
Common points made "against" wirthian languages is that they are seen as more "verbose" and more "rigid". Of course, some will see that as meaning more readable, more maintainable and "safer", while many tend to see this as just plain annoying and counter-productive. The latter seem to be the majority these days, but interestingly, those "arguments" are almost entirely subjective, while the former have at least some objective basis to them.

I don't "get" such battles. I'll very happily use either.

What annoys me much more is all the languages that decided they should look like C while having vastly different semantics to C. Java and JavaScript and C# being the obvious offenders.

Whatever is good about C, it's not the syntax, and most especially not the syntax of declarations.

[SiliconWizard]

Whatever is good about C, it's not the syntax, and most especially not the syntax of declarations.

Oh, I do agree with that. But syntax is part of a language, and a significant part of it nonetheless. And, give C a pascal-like syntax, and many people will likely shy away from it, even if you don't change a single feature except the syntax.

Language designers deciding to make them look C-like syntax-wise is a whole part of that IMHO. It looks like a vast majority of developers prefer that kind of syntax precisely because it is seen as "non-verbose". Heck, if you look at even more recent languages, such as Rust, they seem to go out of their way to further shorten keywords to apparently make them look even less verbose. They also want to get rid of statement terminators (see Go and Swift?). Because even that looks like too much. Etc. This is my view of it, but it seems rather apparent that there is a commonly shared obsession with reducing the "verbosity" of programming languages, sometimes to a ridiculous degree.

[DiTBho]

Back to #define ... OMG u-boot has four layers of nested #define

#define A ... // from (file1, and don't forget to check the right #ifdef, or perhaps it's the #else branch? )
#define B A // from (file2, and don't forget to check the right #ifdef, or perhaps it's the #else branch? )
#define C B // from (file2, and don't forget to check the right #ifdef, or perhaps it's the #else branch? )
#define D C // from (file3, and don't forget to check the right #ifdef, or perhaps it's the #else branch? )

#define again what is defined here of what is defined there of what /// I am lost

That is very confusing because hard to follow (-E doesn't save your days but it helps a lot) and I don't actually know what a line of code does. It's the pATA part because some pATA controllers work in legacy-mode (like ISA cards), some in PCI-mode, and some in PCI-mem-only.

Two lines of C code cost me 6 hours of struggling, rather annoying

Octeon MIPS64 has something similar for their SoCs, and the Wr703 code made for Atheros is a full similar mess.

I seriously hate nested #define, really, I promise I will hug a tree and walk barefoot, but don't do this! PleaZe 

[Siwastaja]

I don't understand why people do not follow normal indentation practices with the preprocessor.

Nesting itself isn't a problem. This is unreadable as well:

Code: [Select]

void func()
{
if(asdf == 123)
{
for(int i=0; i<42; i++)
{
if(condition)
break;
}
}
}

Yet people do exactly this with preprocessor. Except me, I follow normal indentation practices:

Code: [Select]

#ifdef THING
        #if 1==2
                void func()
                {
                        ...
                }
        #endif
#endif

Lines get too long? #include things away.

[brucehoult]

Yah, this is annoying.

emacs by default does not indent preprocessor directives -- it forces them to NOT be indented.

This can be changed by adding the following to your .emacs in the c-mode hook:

(c-set-offset (quote cpp-macro) 0 nil)

[SiliconWizard]

Yah, this is annoying.

emacs by default does not indent preprocessor directives -- it forces them to NOT be indented.

This can be changed by adding the following to your .emacs in the c-mode hook:

(c-set-offset (quote cpp-macro) 0 nil)

I admit I usually do not indent preprocessor directives. It's out of habit entirely; probably from having been exposed to a lot of source code that did not indent them, early on. Also, some compilers did not like it, but that was probably a long time ago.

That's less readable though, so I agree and will try to change habits.

[DiTBho]

Formatting the sources is not a problem, the problem isn't whether you indent or not, the problem is four bloody layers of definitions! One inside the other like a Matryoshka.

I like soviet Matryoshkas, but only when they are made of wood and visually look like a babushka.