Is Anyone Familiar With stdarg.h? I Want To Have A Discussion About This File.
idbruce
Posts: 6,197
I have a C program that I am working on and during compilation, a huge list of warnings are issued. I have not got to the point of weeded them out, but I know that most of them are caused by the use of stdarg.h and the use of various data types. I am looking at having a serious discussion about resolving these warnings, because they annoy me. 
The code works fines and I could probably uncheck the "All Warnings" option in SimpleIDE, at which point all warnings disappear, but I do not want to lose track of any warnings that are not associated with the use of stdarg.h.
The code works fines and I could probably uncheck the "All Warnings" option in SimpleIDE, at which point all warnings disappear, but I do not want to lose track of any warnings that are not associated with the use of stdarg.h.
Comments
Actually Dave, in my instance it is the use of uint8_t and uint16_t data types, however I am sure that the use of int8_t or int16_t would generate warnings as well. To my understanding, you are partially correct. If the data type is not uint32_t or int32_t, providing it is not type char, then it is promoted to a double (that is what I have read). As I am sure you are aware, this problem relates to the sersendf_P function, within sersendf.c, within Teacup. The sersendf_P function then takes the data and passes it along to various functions within sermsg.c for further processing. Additonally as you know, I could not get it to compile, without altering some of the functions and doing various type casts. As mentioned, it now compiles and works fine, but those numerous warnings may be hiding other warnings that I really need to see.
I could try to duplicate the functionality of stdarg.h, but with different data types, but that may be opening up a can of worms.
In sersendf.c, they say this about the sersendf_P function:
This doesn't sound accurate at all, unless it is writing the string to flash, instead of outputting to a terminal. As it stands now (with the files I am keeping), the sersendf_P function is called 43 times by the following various files:
dda.c
dda_lookahead.c
dda_queue.c
gcode_parse.c
gcode_process.c
during the use of these files, an object is being printed, so I cannot see why this information would be written to flash, instead of being display. If is simply display text, then the problem would easily be resolved, by eliminating sersendf.c, sersendf,h, sermsg.c, and sermsg.h, and using print or printf instead.
EDIT: I will add that I have not found proof one way or another, where these strings are going, but I may have overlooked it.
void sersendf_P(PGM_P format, ...) __attribute__ ((format (printf, 1, 2)));
PGM_P is defined as follows.....
#define PGM_P const char *
As metioned in the previous post,.....
At the beginning of sermsg.c it says this....
I presume we are still talking about Teacup here. That code builds and runs on systems with 16 bit ints (AVR) and 32 bit ints (PC simulator) so presumably it can be a big deal to get it to compile for the 32 bit Propeller.
Far better to try and cast any 8 or 16 bit parameters to 32 bit when making the calls if possible.
I can't really say as I as you don't say exactly what sources we are talking about or what warnings are coming out.
I wasn't really talking about altering stdarg.h, but more like creating my own "stdarg.h" + "stdarg.c", renaming them to like "mystdarg.h" + "mystdarg.c" and then use the functions of mystdarg.h..
Yes I am talking about Teacup. However, to be more specific, sersendf_P is a variadic function, which receives an indefinite number of arguments with unkonown data types, similar to printf.
I have to run an errand, but in the meantime, here is a list of warnings.
I will test this theory and let you know the results.
Interestingly when I compile dda.c for the simulator using their make file with GCC on my PC it compiles with the options "-Wall -Wstrict-prototypes -Wno-format -Wno-format-security"
That is to say warm me about everything except those pesky format issues. This suggests that these warnings are known about and have been deliberately suppressed in their Make file and presumably know are not dangerous. Not a practice I condone but there we go.
I would not want to provide a mystdarg.h if I were doing this, at the end of the day whatever mods are made for getting this to work on a Propeller the thing should still be buildable in simulator mode.
I am curious why you say that? What are the real benefits to the simulator, besides debugging?
I really do not enough about the simulator to make any kind of judgement about it's usefulness, but I do know for a fact, that adding the simulator will compound the complexity of the project, especially at this point. As I told Dave, when I get it running, then I could go through it one more time to add the simulator back in.
Looks like the original source correct? Has Bruce posted his modifications anywhere?
If I were you, I would change every use of va_arg in the Teacup code to something like "(uint16_t)va_arg(v,int)". This will eliminate the warnings, and the code will work as expected.
EDIT: I agree with Heater about the simulator mode. It would be cleaner to start with the simulator mode and then add Prop-specific drivers. Your current approach requires working around a lot of AVR stuff. The simulator mode eliminates most of that. Don't be confused by the term "simulator". From what I understand, the simulator mode is fully functional except that it simulates I/O using a serial port or files. I think you could actually drive a 3D printer from the serial output if the 3D printer accepted serial input.
If you really want to jump in....
Then here is a link to the Teacup port thread: http://forums.parallax.com/showthread.php/159950-The-Teacup-Port-A-Work-In-Progress-3D-Printer-Firmware, but go to the end, because for a while, I was going in useless circles.
Oh no, I am not starting over again
Anyway, looking at sersendf.c, that's a highly modified version of printf. Because of the special characters (the 'q' for instance), I wouldn't have marked it as a printf function in the first place. In the header file, you can see the prototype is written as:
I'd take off that format attribute. I'd also go through all the instances using %ld and %lu and switch them to %u and %d. Presumably, int is 16 bits on the arduino and long int is 32-bits, which is why they used ld and lu. But... the Propeller is infinitely cooler because we get 32-bit ints
I can't help myself. Here's the long and complicated CMake file. All 33 lines of it.
################################################################################ ### Template code. Do not modify # # cmake_minimum_required (VERSION 3.0.0) # # Aside from cmake_minimum_required, this must be the first two lines # # of the file # file(TO_CMAKE_PATH $ENV{PROPWARE_PATH} PROPWARE_PATH) # include(${PROPWARE_PATH}/CMakePropellerHeader.cmake) # ################################################################################ set(BOARD GENERIC) set(MODEL cmm) set(COMMON_FLAGS "-Os") project(Forger C) create_simple_executable(${PROJECT_NAME} ${PROJECT_NAME} Adafruit_ADS1015 config dda dda_lookahead dda_maths dda_queue debug gcode_parse gcode_process home pinio propellerized sergcode sermsg sersendf)I should have been following my original intent all along, but I wanted to take baby steps. I have figured out how to resolve the warnings and I don't know if it is the right thing to do, but I am going to run with it.
sersendf.c, sersendf.h, sermsg.c, and sermsg.h, will soon be a thing of the past, and these files will all be deleted. functions of these files will be replaced with "print".
Replacing stdarg would not help this situation, since the warnings are about the printf formats, not about anything that stdarg.h does. Besides which, Heater is very much correct that replacing standard header files is usually a bad idea. It's not possible to change stdarg.h behavior in this case -- the compiler itself is promoting int8_t and int16_t to int, and is doing so in accordance with the language definition. But that's a red herring anyway, because the warnings in your message are not because of variable promotion, but because the compiler is checking the string as if it were a printf format, and it isn't.