stanfordpl / cpputil Goto Github PK

Add an argument type that functions like a flag and overrides the value of another argument. This way, overrides will print with the --debug_args flag.

Some things need const raw data.

The implementation is looking cluttered.

Otherwise you get multiple include errors.

If a config file is provided, that ends in a line with a comment, and no newline, then the parsing code loops forever. For instance, the last line could be

--foo bar # some comment

It is important that the file ends in no newline for the bug to occur.

It would be nice to have a way to get a base-16 string representation of the contents of a bitstring.

I'm going through the valgrind memcheck output, looking for the culprit of my bug. I don't think this is the real culprit, but there are a few places that the bit iterator for bitstring performs an undefined read. I think I know how to fix this and will do so in a moment.

warnings about signed and unsigned compares

Make it.

At the moment, when --example_config is used, the tool continues executing. This should change to exiting with status 0.

What the name says.

Let's make an io filter.

When I specify both on the command line (without other options, but with a config file), the --debug_args seems to be ignored completely.

io/fail.h adds an error string and methods for managing the failbit in a stream.

Generalize this feature to a warning bit and a list of warning messages.

Bugfix is to remove annotation.

For popcnt and tzcnt. This is affecting the behavior of BitStrings which is affecting backwards compatibility for STOKE.

What license is this repository under?

need to make a few changes so we can compile stoke with meaner warning flags

The primary mechanism for communicating parse errors to the CommandLine library is to set the failbit in an iostream. This is nice because it allows for the use of built-in parsers and doesn't require any code bloat for people writing their own parsers. All you do is implement a functor and you're done.

The downside is that the generic parse error message that gets printed is rather cryptic. It would be nice to be able to store not just the fail bit in an iostream, but also an error message. We can do this pretty easily with xalloc and pword.

String parsing doesn't work correctly when reading from config files.

"{ 0 ... 9999 }" is so much better than a thousand lines of output.

If you don't specify a required argument, --example_config won't work. It would be nice to fix this for the stoke release; would one of you be willing to take it on?

At the moment, parsing silently ignores the error.

I would like to implement support for required arguments. If one or more required arguments aren't passed via the command line, then an error message is shown and the system exits with status 1. The implementation would add a "required" method, that can be chained just like other methods to set properties or arguments. For instance, one could have

FileArg<TUnit, TUnitReader, TUnitWriter>& target_arg =
  FileArg<TUnit, TUnitReader, TUnitWriter>::create("target")
  .usage("<path/to/file.s>")
  .description("Target code")
  .required();

Thoughts, objections? In STOKE, there are a bunch of arguments that are clearly mandatory, but no error is given if they aren't provided. This feature in cpputils would allow us to improve that situation.

At the moment, command line arguments are sorted alphabetically. However, often times developers (e.g. in STOKE) will write out arguments in a natural way, and sorting them alphabetically destroys that order.

Should we make sorting at least optional (and maybe default to false)? Or is there a reason for sorting them alphabetically that I don't see?

It would be very valuable if we printed the default value with arguments when showing the help. This would make it much easier to use certain tools.

Now, some default arguments may be hard to print (e.g. because the take many lines). We could have a best-effort implementation, that shows the default for all the arguments which can be printed in one line, say. In practice, this would cover most arguments, and the remaining defaults could still be viewed using --debug_args with some additional effort.

Thoughts? I would volunteer to implement this.

Let's refactor this into here.

These should only be enabled via a #define, as most of the time they make debugging harder.

Makes it much easier to know what's going on.

Or something to that effect. I'm getting some segfaults.