Utilize getopt.h for command line argument processing?

[martonmiklos]

Hello @howerj

First of all many thanks for sharing this project, it looks like is going to be very helpful for me!

Currently I am planning to add some features to the tool like:

• Parametrizable indentation of the output source (tabs/spaces, number of spaces)
• I would like to be able to generate code without generating the CAN ID in the function names

These changes would require to add more command line arguments, and handling them with the current processing method seems to be cumbersome. My suggestion would be to refactor the argument processing to use getopt.h provided functions. If you are open to such a change I can came up with a PR before start implementing my improvements.

[howerj]

Hi Marton,

Those changes sound good, however I do not like the external dependency on getopt, I know it is available on Unixen, but not Windows. What you could do however, is integrate getopt itself into the library, see

https://stackoverflow.com/questions/10404448/getopt-h-compiling-linux-c-code-in-windows

For a simple implementation (you should rename the 'getopt' function to something else though). I've put the reasoning in one of the pull requests you've raised, I want this program to be simple to compile, install and integrate into both Windows/Unix builds.

Thanks,
Richard.

[martonmiklos]

Hi Richard,

Have you considered using MingW or Cygwin on Windows for compilation?

I know an open source tool called (flashrom)[https://github.com/flashrom/flashrom] where the MingW is used for compilation and it uses the same approach as dbcc: one general Makefile (no autotools).

I would help happily in the tweaking and testing MingW build support.

[howerj]

Ah, yes, I myself use MingW and/or Cygwin on Windows for compilation, the issue is other people and whatever environment they are using. I do most of my testing on Debian, and only occasionally Windows.

If you look at #14, there's a pull request from someone using MSVC (the pull request actually pulls in dependencies specific to the Windows C library, so won't be merged as is). So a MingW/Cygwin only solution isn't acceptable, but by integrating our own getopt solution (I can do this, although probably not tonight), we can satisfy all constraints.

[martonmiklos]

Alright, I am not against of having our own getopt.

I just brought up the MingW/cygwin because I am afraid that the "using only pure C implementations" might bring up some limitations or at least increased efforts in the future. I have just scratched the surface and I hit 3 things with very basic things: libgen, basename, getopt.

But anyway I am fine with your decision.

[howerj]

Ok, I've added a getopt implementation (along with untested floating point support), but I'm not using it at the moment. There's now also a version of basename taken from musl-libc.

As for out of memory error when reading a directory, I'll have to think of the best way of fixing that. It might mean having to write an OS wrapper for the functionality for detecting if we can write to a file.