1

for some reason the wrong opensslv.h header is being included via cmake, or so I think. I would like to be sure and print out which value for "OPENSSL_VERSION_NUMBER" was compiled into my binary. How do I do that?

Blub
  • 13,014
  • 18
  • 75
  • 102
  • `std::cout << OPENSSL_VERSION_NUMBER << '\n';`? – Galik Jul 13 '16 at 17:09
  • @Galik is there any specific reason you're mixing C and C++? Why not use `std::endl`? If you want to use `\n` it should just be a `printf`, if you're going to use `std::cout` then that should be the standard held for all statements and should continue to use the standard library. – Ingenioushax Jul 13 '16 at 17:11
  • Galik, it's a library – Blub Jul 13 '16 at 17:15
  • 3
    @Ingenioushax: What are you talking about? `'\n'` is a perfectly valid C++ character literal. – Benjamin Lindley Jul 13 '16 at 17:17
  • 3
    @Ingenioushax `\n` adds a newline. `std::endl` adds a newline *and* flushes the stream. Two different things. `\n` is perfectly fine (and preferable) when you just want the newline and not the flush. – Jesper Juhl Jul 13 '16 at 17:17
  • 1
    @Ingenioushax Using `'\n'` is not "mixing C and C++" - ending a line with `'\n'` is perfectly valid C++. The only real difference between the two is that `std::endl` [also flushes the buffer](http://stackoverflow.com/a/213977/1600898). – user4815162342 Jul 13 '16 at 17:18
  • @BenjaminLindley, I know it's _valid_ C++. So is `int *myInt = (int*)malloc(500 * sizeof(int));`. Is it valid? Yes. Does it work? Sure. Is it conforming to the standards? No. While `\n` is a perfectly valid escape sequence, _I_ wouldn't put it as the preferred method for a line ending in C++. – Ingenioushax Jul 13 '16 at 17:28
  • @Ingenioushax: But *why* wouldn't you? And what's it have to do with "mixing C and C++"? – Benjamin Lindley Jul 13 '16 at 17:30
  • @BenjaminLindley, **A**) I think it's laziness unless embeeded in a string (errr). The following is perfectly fine in my book, but still falls in the lazy category `cout << "This is a string\n";`. **B**) It's much harder to find '`\n`' than it is `<< endl` if you need to hunt a bug or implement a feature change. **C**) A decent number of developers don't _know_ that there is a STDOUT and STDIN buffer. – Ingenioushax Jul 13 '16 at 17:34
  • @Ingenioushax We'll have to agree to differ. I would say that ending a line with `\n` should be the recommended method over `std::endl` which can be less efficient. Also its easier for maintenance if its sent as a separate character and not embedded in the string literal. – Galik Jul 13 '16 at 17:38
  • @Galik: I can see that point, and I don't necessarily disagree with the statement. I suppose that's why coding standards for grander issues are for the greater good of humanity. :D – Ingenioushax Jul 13 '16 at 17:40
  • @Blub oopsie, of course. You could try `$ strings /path/to/library.so` – Galik Jul 13 '16 at 17:42
  • @Ingenioushax Both `\n` and `std::endl` are entirely valid ways of sending a newline in C++, and each has its uses. If you're only outputting a single line, go with `endl` to flush the buffer afterwards. If you're outputting multiple lines, use `\n` between each line, and `endl` after the final line. You'll generally get more efficient results that way. The main benefit of `endl`, after all, is that it both sends `\n` and flushes the buffer for you at the same time, so you don't have to do both operations separately. – Justin Time - Reinstate Monica Jul 13 '16 at 18:14

1 Answers1

0

As the comment by @Galik mentions, you can print out the value of the macro if you can edit the source.

If all you have is a binary then it gets hard, since the preprocessor will have replaced the macro name with its value before the compiler ever sees the source. So the binary does not contain any "link" back to the original macro name.

Some compilers (in my experience clang does it best) can embed such information in the binary when building with debug symbols enabled so it can print better error messages and make debugging more effective. But in an optimized binary without debug symbols you are close to being out of luck. That is, unless you start digging through a disassembly of the binary around where you know the macro is used and you know potential values it might take. Then you might be able to dig it out.

Jesper Juhl
  • 30,449
  • 3
  • 47
  • 70