- What does operating on raw bytes mean in a C++ context? - 3 Updates
- Range-based for loops when you don't process everything in the container. - 1 Update
- Module libraries - 1 Update
| Paul <pepstein5@gmail.com>: Nov 03 01:52PM -0700 A cryptopals.com problem involves translating hex to base 64. For example, 49276d206b696c6c696e6720796f757220627261696e206c696b65206120706f69736f6e6f7573206d757368726f6f6d should produce SSdtIGtpbGxpbmcgeW91ciBicmFpbiBsaWtlIGEgcG9pc29ub3VzIG11c2hyb29t I'm confused by the instruction: "Always operate on raw bytes, never on encoded strings. Only use hex and base64 for pretty-printing." What does "raw bytes" mean in terms of the input/output parameters. Presumably it means I shouldn't have a const std::string& as input and a std::string as output? Does anyone know what it means to translate hex to base 64 "by operating on raw bytes" in a C++ context? Thank you, Paul |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 03 10:17PM +0100 On 03.11.2018 21:52, Paul wrote: > should produce > SSdtIGtpbGxpbmcgeW91ciBicmFpbiBsaWtlIGEgcG9pc29ub3VzIG11c2hyb29t > I'm confused by the instruction: "Always operate on raw bytes, never on encoded strings. Only use hex and base64 for pretty-printing." As I read it, the instruction is so unclear as to be pretty meaningless. > What does "raw bytes" mean in terms of the input/output parameters. I would guess that given a string "49276d206b", that that string itself should not be encoded as base 64, but rather the byte values that it *denotes*, should be so encoded. Then you run into two issues: the assumed byte size (8 bits? 16 bits? what?), and the endianess assumed for the string. But the example clears that: you can just try the most reasonable assumption first, and other assumptions if that doesn't reproduce the example. And if none of these match the example, then perhaps my interpretation of the instruction is wrong. So. :) > Presumably it means I shouldn't have a const std::string& as input > and a std::string as output? No no, `std::string` is fine as container of raw bytes. E.g. it's used a raw byte container by some Google networking API. So, `std::string` doesn't necessarily imply any encoding. Where an encoding has to assumed, then usually the only reasonable assumption is the program's Basic Execution Character Set, as discussed in the standard. But if that isn't UTF-8, then in some cases one has to be very careful about interpreting a textual string as BECS or UTF-8. > Does anyone know what it means to translate hex to base 64 "by operating > on raw bytes" in a C++ context? I don't, but my thoughts about it above. "Raw byte" just means uninterpreted byte values. Cheers!, - Alf |
| Paul <pepstein5@gmail.com>: Nov 03 03:10PM -0700 On Saturday, November 3, 2018 at 9:17:56 PM UTC, Alf P. Steinbach wrote: > "Raw byte" just means uninterpreted byte values. > Cheers!, > - Alf Thanks a lot. Ok, so std::string is fine. What would be an example of something that you're not allowed to do? |
| Manfred <noname@add.invalid>: Nov 03 06:16PM +0100 > to have, it will have that behavior only because the memory being read > has unpredictable contents, not because of any more esoteric problem due > to interacting with an optimization. This happens to be a long known bug in gcc: https://gcc.gnu.org/PR18501 |
| Thiago Adams <thiago.adams@gmail.com>: Nov 02 07:54PM -0700 On Friday, November 2, 2018 at 6:51:32 PM UTC-3, Paavo Helde wrote: > library author wanted to build their library, you just want to compile > it afresh with whatever options your project happens to have and > incorporate the result in your project. The compiler options can be passed at the beginning. But, the same compiler options will be used in all files unless we can specify this compiler setting per file. (For instance, this is possible for warnings) > In your project, add ../otherproject/*.c or "Add Existing:Select All" to > your sources. > Voila, done. Works fine for some Boost libraries, for example. The real code will have several files. This solution does not scale and don't compose well compared with this pragma source. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment